Client memory: Data Model

9 min read

Remy keeps one client memory per client: a folder of markdown pages in the bank's knowledge base, under /home/{username}/clients/. This page describes the memory categories, their fields and field types, who may write each field, whether a value is persisted or read live, how long data is kept and how changes are recorded. The core system (CRM, KYC, custody and portfolio systems) is the golden source.

Memory categories and fields

Category	Page	Ownership	Main fields (type) & Source*
Overview	`index.md`	Derived	Snapshot (text), Source: Derived from the other topic pages Lifecycle stage (enum), Source: Core System Key figures (amount, date), Source: Derived from the other topic pages
Compliance	`compliance.md`	Mirror	Identity data (text, date, identifier), Source: Core System Tax residence (text), Source: Core System Investor classification (text), Source: Core System Document register with expiry (table: document, issue date, expiry date, state enum), Source: Core System
Balance sheet	`balance-sheet.md`	Mixed	Managed assets (amount), Source: Core System Held-away and illiquid assets (amount), Source: Client interactions Liabilities (amount), Source: Core System Share of wallet (percent), Source: Core System
Cash flow	`cash-flow.md`	Mixed	Income sources (text, amount), Source: Core System, enriched with client interactions Spending (amount), Source: Core System, enriched with client interactions Future outflows (amount, date), Source: Core System, enriched with client interactions
Goals	`goals.md`	Derived	Goals (table: type enum, amount, target date, priority, flexibility, owner enum), Source: Derived from the other topic pages
Risk and preferences	`risk.md`	Mixed	Risk willingness (enum), Source: Derived from the other topic pages Capacity and behaviour (text), Source: Client interactions Preferences (text), Source: Client interactions Constraints (text), Source: Core System, enriched with client interactions Policy bands (table: asset class, target, band, state enum), Source: Core System
Tax	`tax.md`	Mirror	Tax residence (text), Source: Core System Account location (enum), Source: Core System Realised gains and losses (amount), Source: Core System
Mandate	`mandate.md`	Mixed	Mandate facts (identifier, text, date, amount), Source: Core System Performance (table: period, portfolio, benchmark in percent), Source: Core System Narrative & Insights (text), Source: Client interactions
Relationship	`relationship.md`	Mixed	Household (table: name, role), Source: CRM, enriched with client interactions Communication preferences (text), Source: Core System, enriched with client interactions Interests (text), Source: Client interactions One-off mentions (text, expiry date), Source: Client interactions
Commercial	`commercial.md`	Mirror	Assets under management (from Balance sheet) (amount), Source: Core System Segment (text), Source: Core System Revenue (amount), Source: Core System
Commitments	`commitments.md`	Mixed	Interaction log (table: date, channel, subject), Source: Core System + mailbox Commitments (table: promise, owner, due date, state enum), Source: Client interactions Advice given (table: date, recommendation, decision enum), Source: Client interactions
Network	`network.md`	Agent-proposed	Connections (table: person, relationship type enum, date, source, handling rule), Source: Client interactions
In flight	`in-flight.md`	Derived	Open cases and actions (table: item, owner, deadline, state enum), Source: Derived from the other topic pages
Screening	`screening.md`	Agent-proposed	Findings pending review (table: category enum, date, source, disposition enum), Source: Core System + external screening sources (read live)
Source of wealth	`sow.md`	Agent-proposed	Wealth components (table: component enum, amount, evidence coverage enum), Source: Core System, client interactions + public evidence (read live)
Referrals	`referrals.md`	Agent-proposed	Introduction shortlist (table: person, reason, status enum), Source: Client interactions + external research (read live)

Each client memory also holds a change log (changes.md) and a list of its sources (documents.md). The bank can add fields, take categories out of scope and extend the list of data that is never stored, as configuration and without a release.

* The core system is the golden source and always takes precedence. Remy adds information from client interactions (meetings, email, chat), each traceable to its source.

Field types

Type	Format
Text	Free text
Date	`YYYY-MM-DD`
Enum	One value from a fixed list
Amount	Currency code and amount, for example `CHF 1,200,000`
Percent	Number with unit
Identifier	Client or system ID
Link	Reference to the source of the fact
Table	Repeated rows with named columns

Ownership flags

Flag	Meaning	If the source has nothing
Mirror	Copied from the bank's system of record. Never inferred.	Left blank
Mined	Extracted by Remy from the advisor's sources, with source and date	`no data on file` or `not applicable`
Agent-proposed	Drafted by Remy, marked `proposed` until a person confirms it. Never shown as settled.	Stays `proposed`
Derived	Built by Remy from other pages in the memory. Never edited directly.	Follows its source pages
Mixed	Label for a category whose sections carry different flags. Each field is exactly one of the flags above.	Per field

Persisted vs. retrieved live

Every value stored in the memory is persisted as markdown, so that a brief can be reproduced from the memory alone and every fact keeps its source, date and confidence. What differs per category is where the authoritative value sits and when it is re-read.

Three patterns are used:

Mirrored copy - the value is copied from the system of record and persisted with a last sync date. The memory holds a dated copy, never the record itself. The system of record remains the golden source.
Memory-only - the value exists only in the memory, extracted from the advisor's own sources or stated by the client. No system of record holds it.
Read at run time - the value is not persisted at all. Web search, and any check that must be current at the moment of use, is executed during the run and never cached.

Category	Where the authoritative value sits	When it is re-read	If the golden source changes
Overview	Derived in the memory from the other topic pages; lifecycle stage mirrors the core system	Rebuilt on every refresh run, and on demand	Follows the pages it summarises
Compliance	Mirror of the core system, persisted with a `last sync` date; the document register is re-read at run time when an action depends on it	Refresh run; live when an action is triggered	Core system wins; the mirror is overwritten on the next sync and the change is written to the change log
Balance sheet	Mirror of the core and portfolio systems; held-away and illiquid assets are mined from client interactions	Refresh run; live when a figure is used in a brief or an action	Core system wins on the mirrored figures
Cash flow	Core amounts mirrored; the client's own account of income, spending and future outflows is mined	Refresh run	Core system wins on the mirrored amounts; the mined context is kept, dated and left untouched
Goals	Derived from the other topic pages. No system of record holds a client's goals	Refresh run, and whenever the advisor confirms a change in chat	Not applicable
Risk and preferences	Policy bands and constraints mirror the core system; willingness, capacity, behaviour and preferences are mined	Refresh run; bands re-read when the drift monitor runs	Core system wins on bands and constraints
Tax	Mirror of the core system	Refresh run	Core system wins
Mandate	Mandate facts and performance mirror the core system; narrative and insights are mined	Refresh run; performance re-read for a meeting brief	Core system wins on mandate facts and performance
Relationship	Household and roles can mirror the CRM; communication preferences, interests and one-off mentions are mined	Refresh run; one-off mentions are removed when their expiry date passes	CRM wins on the mirrored household and roles
Commercial	Mirror of the core system	Refresh run	Core system wins
Commitments	The interaction log mirrors the core system and the mailbox; commitments and advice given are mined	Refresh run, plus the actions sync that reads Sent Items	Core system wins on the interaction log
Network	Agent-proposed; persisted as `proposed` until a person confirms it	Refresh run	Not applicable
In flight	Derived register, rewritten by the monitor and meeting-brief skills	Monitor run	Follows the pages and registers it draws on
Screening	Findings persisted as `proposed`; the external sources behind them are queried live at run time and never cached	Screening monitor run	Not applicable - a finding stays `proposed` until it is dispositioned by a person
Source of wealth	Components and evidence coverage persisted; public evidence read live at run time	Monitor run	Not applicable
Referrals	Shortlist persisted as `proposed`; the research behind it is read live at run time	Monitor run	Not applicable

Refresh frequency

Refresh run: nightly sync and mining. Monitor run: scheduled check for one topic (screening, source of wealth, referrals, in flight).

The refresh run is a scheduled task per user, not a central batch job. The shipped default is nightly, so that the advisor's day is ready before they start; the cadence is set in the scheduler and can be retuned per monitor without a release. Mining is incremental - a source is mined again only when it has changed, and unchanged records are not reprocessed.

Beyond the schedule, a value is re-read live from the source system whenever an action depends on it being current - for example a document register checked before a letter goes out, or portfolio figures pulled for a meeting brief - so that what the advisor acts on reflects the source system at that moment.

If a connector is unavailable, the run states which sources were used and which were not, falls back to the last mirrored value together with its sync date, and says so. It does not guess, and nothing is lost: the next run reads everything since the last entry in the mining log.

Update policy

Read directly, write only through Remy. The memory can be read directly. Updates go only through Remy, so the ownership flags and the rules on this page are enforced on every write.
The golden source always wins. Where a field is a mirror, the system of record is authoritative and the memory holds a dated copy. A change in the source system overrides the memory at the next sync, and the change is recorded in the client's change log.
No write-back into source systems. Core systems are read-only. No value is written back into the CRM, the KYC system or the custody platform. Write-back is a separately governed decision outside the package.
Mirror fields are never inferred. If the system of record holds nothing, the field is left blank rather than filled in.
What a person states is protected. Facts entered or confirmed by the advisor are never overwritten by automation.
Conflicts are surfaced, not resolved silently. When two sources disagree, both values are kept with their source and date, and the advisor decides.

Metadata on every fact

Attribute	Type	Values
Source	Link	Where the fact came from
Date	Date	When the fact was established
Basis	Enum	`client-stated` · `firm-confirmed` · `firm-inferred` · `estimated` · `observed`
Confidence	Enum	`confirmed` · `probable` · `unconfirmed`
Origin	Enum	`source-file` · `advisor-entered` · `chat-observed` · `core-sync` · `external-live`
Last sync	Date	On mirror fields only
Confirmation	Enum	`proposed` · `human-confirmed`, on agent-proposed fields only

Data retention*

Data is always kept warm. Nothing in the memory decays or expires on a timer, except one-off mentions (see below).
Every fact carries the date it was established, and mirror fields the date of their last sync. Remy and the advisor use these dates to judge whether a fact is current enough to rely on.
One-off mentions carry an expiry date and are removed once it passes.
A single fact is removed only through an explicit, logged "forget".
Offboarded clients are archived, not deleted.
Backup and retention follow the bank's existing knowledge-base rules.
Full erasure of a client's memory, including its version history, goes through a deletion process run by Security & Compliance.

* This is the default behaviour. It can be customised to specific customer needs if required.

Versioning

Every write adds an entry to the client's change log: which page changed and what was added or removed. Entries are never rewritten.
The knowledge base keeps every earlier version of every page.
Changes to the bank's configuration are versioned by the knowledge base and never overwritten by an upgrade.