Three-Tier Definitions: the Order That Works

The outcome of an online supervision platform is decided at the first step. The correct order is: legal entity ledger, then equity holdings ledger, then the metric definition table, then reporting mapping, and only after that the supervisory dashboard. Projects that stall usually open with a reporting template or a dashboard, because those are the most visible deliverables and the easiest to report upward. The cost is deferred: every province, city and district discrepancy lands in the integration phase, and district-level entities have the weakest reporting capacity and the least stable definitions. The project then extends indefinitely on the last fifth of its scope.

Why the entity ledger precedes reporting

Divergence across three tiers starts as an identity problem, not a metric problem. The same enterprise exists as three objects: a group-internal code at provincial level, a registry name at city level, and an abbreviation or historical name at district level. Until identities converge, every metric requires a manual mapping, and that mapping lives in one coordinator’s spreadsheet and memory.

Look-through shareholding depends on the same step. Only with unique entities and a closed ownership chain does “indirect holding down to the operating company” become a computable query. Otherwise every look-through result needs human verification, and verification cost compounds by tier. The state-owned capital and guidance fund practice lists entity and holdings structure as its first deliverable for this reason.

Three kinds of definition divergence

Divergence type	What it looks like on site	Root cause	Convergence method
Definition	Does net assets include minority interests; is investment value the agreed or paid-in amount	Each tier historically served a different recipient and evolved its own template	One definition table: metric, formula, exclusions, currency, owner — signed by business, risk and reporting
Timing	Ownership change booked at registry acceptance or at resolution effect	Source timestamps do not match the assessment period boundary	Two timestamps kept side by side: event date and capture date; assessment uses the event date
Scope	Are minority stakes included; are fund-channelled investments included	Supervisory scope and consolidation scope used interchangeably	Explicit scope switches with a cited basis; inclusion and exclusion both traceable to a clause

Identifying which kind you face sets the cost of the fix. Definition divergence is solved on paper. Timing divergence is solved in the data model and requires engineering. Scope divergence is solved by a decision: no technical design can tell the client whether a minority stake counts.

The five steps and what each one delivers

Check the project plan against this list; a missing item means the order has already been broken.

• Entity ledger: unique identifier, alias table for historical names, parent-child assignment with change history. Acceptance test: one query answers which tier and which group an enterprise belongs to.
• Equity ledger: agreed amount, paid-in amount, ownership change chain, supporting documents. Acceptance test: a timeline of holding changes for any named company.
• Metric definition table: formula, source fields and owner for every supervisory and management metric. Acceptance test: a version number and signature record.
• Reporting mapping: each exit mapped from template field to definition-table field, with an explicit gap list. Acceptance test: one real template exported in full with no manual fill.
• Dashboard and alerting: consumes only the four outputs above and introduces no new data entry.

Steps four and five cannot swap. Build the dashboard first and teams will enter data to satisfy it; those entries become a fresh source of definition divergence. This is the most common rework path we see.

Field-level permission is not a bonus feature

Once supervision data is centralised, sensitivity becomes a field question: unit-level valuation cost, executive remuneration, litigation and guarantee details. Visibility cannot be hand-waved by role name. Catalpa’s published technical baseline describes function, row and field level permissions, AES-256 encryption at rest with TLS 1.3 in transit, deployment across public cloud, private cloud and intranet, and domestic-stack compatibility (see security and compliance).

In a three-tier setting the right question is not “can districts see provincial data”. It is “which field is visible to which role at which tier for which purpose, and did this access leave a record”. That question can be answered on the spot with one test account at acceptance, and written into the contract before build.

When we advise against starting with a supervision platform

Three cases. First, the group has not confirmed its own enterprise list and ownership relations; run an asset and equity verification exercise instead, because software will only digitise the uncertainty. Second, subordinate enterprises carry no contractual duty to report; online supervision turns reporting into an obligation, and without that mandate you get systemic late filings that the group eventually fills in on their behalf — data with no supervisory value. Third, the stated goal is “filing compliance as a KPI”; designs centred on submission rates generate back-filling and cosmetic values, and they fail first when an audit traces a figure back.

The value of three-tier convergence is not a single screen showing everything. It is that the same metric resolves to the same number at any tier, and that the number can be recomputed from evidence. Get the order right and the dashboard is the last piece. Get it wrong and the dashboard is the most expensive decoration in the programme. Related acceptance definitions appear in provincial SOE supervision consolidation and data governance and metrics.