M/HQ Group · Stage 2 · Appendix C

Field map and source of truth

Where each data point lives, which system owns it, and how it stays consistent across the core and the spokes.

Prepared for: M/HQ Group · in response to the architecture review of 20 July 2026
Status: Foundational v1 · domain level · expands as we go deeper into ViewPoint and the other data sources
Reads with: the target-architecture diagram in the main proposal

C.1What this map is for

The proposal shows the shape of the platform: inputs captured once, an owned data core as the single source of truth, and specialist spokes around it. This appendix answers the next question: for each kind of data, which system holds the authoritative version, and how are contradictions prevented.

It is deliberately domain level, not field level. It reflects what is known today and firms up as the team works through ViewPoint and the other existing sources during WS0. Every row carries a confidence marker so nothing reads as more settled than it is.

Confirmed understood today Indicative firms up in WS0 / ViewPoint review Proposed our recommendation, to agree

C.2The rule that prevents contradictions

The concern raised in review was the right one: when two connected systems hold the same data point and they disagree, which one wins. The answer is a single, consistent rule.

At onboarding, data flows one way. A new client or entity is captured once through the ingestion layer, cleaned, and written into the core. The core then populates the spokes. There is no second source to disagree with.
After onboarding, the core stays the master. Spokes may write back (an invoice raised, a status changed), but every write is time and date stamped and recorded in an audit log. A later stamp supersedes an earlier one; it is treated as a new entry, not a duplicate, so the same record is never in two states at once.
Significant changes pass through approval. Routine changes are absorbed automatically. Changes to protected fields (for example an amount owed, a total billing figure or an invoice date) route to a Group approver before they land. The Group owns those decisions.

How the core stays consistent. One-way capture at onboarding removes the contradiction at the source; after that, the core remains the master record and every write-back is stamped, logged, and approval-gated where it matters.

A worked example

Take a real sequence, of the kind that happens dozens of times a day:

An invoice is issued to a client on 20 July at 5:00pm. The core records it and the data is written to Xero, stamped with that time.
At 6:00pm the invoice is voided in Xero. That change flows back and the audit log now holds two entries for the same record: the 5:00pm write, and the 6:00pm entry that supersedes it. The later stamp wins, so the record is never in two states at once.
Because a void is routine, it is absorbed automatically. No one is asked to intervene.
Now change the case: the same invoice is edited from AED 50,000 to AED 500,000. That is a protected field and a significant delta, so instead of landing silently it routes to a Group approver, who confirms or rejects it before it takes effect.

The concern raised in review, that reconciliation should not become a manual chore, is answered by this split: the system absorbs the routine automatically and reserves human attention for the few changes that genuinely warrant it. In practice that is a handful a week, not a constant queue, because the source of truth stays in sync by design.

C.3Where each domain lives

Which system is authoritative for each kind of data, whether it sits in the core or stays in its spoke, and how it keeps in step. Where a specific tool is still being selected, the source of truth is the function, and the tool is confirmed at WS0.

Domain	Example data	Source of truth	In core	How it syncs	Confidence
Client / entity master	legal name, entity ID, ownership / UBO, addresses	Core	Master	one way at onboarding, then core-owned	Confirmed
Onboarding / CDD case	onboarding status, documents collected, intake risk rating	Each entity's MLRO entities onboard separately	Status	to core on completion	Confirmed
KYC / screening	screening result, PEP / sanctions flags, monitoring status	KYC360 (internal, daily) ComplyAdvantage (Rethink / RAA)	Flag mirror	daily · event driven	Confirmed
Corporate secretarial	minutes, resolutions, filings, registers, licence renewals	ViewPoint · OneDrive (shared drives)	Reference	to core	Confirmed
Regulatory & compliance	ADGM authorisations, policies, filing deadlines	ViewPoint · OneDrive (shared drives)	Reference	to core	Confirmed
Tax	registrations, VAT / CT returns, filing calendar	ViewPoint · OneDrive (shared drives)	Reference	to core	Confirmed
Audit (RAA)	engagement status, working papers	Audit tenant ADGM entities · linked at entity level	Link only	minimal · entity link	Confirmed
Finance: group revenue & client billing	invoices issued, amounts due, revenue by client, cost-of-sale	Core (relevant subset)	Master (subset)	from each entity's accounting · webhook + audit log · approval-gated on amount / date	Confirmed
Finance: full internal ledger	journals, expense lines, marketing / vendor payments, reconciliations	Each entity's own accounting (Xero today, per entity)	Stays in spoke	none · remains with the entity	Confirmed
Documents / identity	passports, IDs, contracts, document metadata	ViewPoint · OneDrive · document store	Metadata	schema-agent managed · new fields admin-approved	Confirmed
Feeder / introducer	introducer per client, referral source, intro / feeder fees	Core (relationship)	Master (subset)	from onboarding + accounting	Indicative
HR / payroll (internal)	headcount, roles · compensation detail	Internal HR / accounting	Headcount subset	headcount / utilisation to core · comp detail stays in HR	Confirmed

Reference = the core holds the pointers and the client relationship (what is owed, when it is due, what has been done), not the full working detail, which stays in the specialist tool.

C.4Finance: what sits in the core, and what does not

Finance is the domain where the distinction matters most. The core is not an accounting system and does not try to be one. Each entity keeps its own internal accounting (Xero today), held separately; the core draws only the relevant slice from each and brings it together, which is what lets the Group see across entities without opening any ledger.

In the core

The relevant finance data, consolidated across entities: invoices issued, amounts due, revenue by client, and the cost-of-sale and feeder data the Group analyses. This is what makes the core answer questions like "how many unique clients, how much revenue across the Group" without opening any ledger.

Stays with each entity's accounting

The full ledger: journals, line items, reconciliations, and marketing / vendor expense. Swapping an entity's accounting system is a migration between accounting tools, not a re-plumb of the core, because the core never held the ledger in the first place.

C.5Segregated data: the R&C client tenant

Walled off · not in the shared core

Reg & Compliance client data is held in a separate tenant of the record system, with firewalls between tenants. It is never written into the Group's shared core and does not appear in the field map above. It is linked only where the architecture explicitly permits, and governed separately. The audit tenant is likewise separate and linked at entity level.

C.6How this map is used from here

It is the working reference for WS0: as tool selections are made and the ViewPoint review deepens, the Indicative rows are confirmed and the map is versioned.
It becomes a living data dictionary, handed over as part of the platform, so the Group can always see where each data point lives and who owns it. That is one of the ownership deliverables set out in the proposal.
It is the basis for the governance rules: which fields are protected, what routes to approval, and who signs off.