System Selection: Definitions Before Features
Feature lists converge; field ownership, reporting exits and metric formulas do not. Four decisions, a meeting checklist, three cases to avoid.
The first disagreement in a selection process is not about features. It is about who owns a field definition. Feature lists are the easiest thing to compare and the easiest thing to equalise: place two vendors’ lists side by side and the differences usually cover less than a fifth of the items. Four other questions decide the experience in the two years after signature — who defines each field, how many external reporting exits exist, whether core metrics are calculated or typed in, and which steps should stay manual. Demos rarely raise these four, so contracts rarely mention them.
Whose definition ends up inside the software
The most dangerous fields in an investment system look naturally standard: investment amount, ownership percentage, exit multiple, paid-in capital, fund size. Each one carries a different value across four sources — the signed investment agreement, the company registry, the portfolio company’s financial statements, and the regulator’s template — and each value is defensible on its own terms. The selection question is not whether a vendor has the field. It is where the definition is written, which role owns it, and who approves a change.
Catalpa places “data dictionary definition and field-level customisation” in its published technical baseline (see Data governance and metrics) for exactly this reason. If the dictionary does not live inside the system, the system quietly makes one unauthorised definition on behalf of the whole organisation. That definition never raises an error. It surfaces during an audit question.
| Comparison item | Typical practice | Our definition | Failure signal |
|---|---|---|---|
| Field definition | Field names and types in a requirements document | Owner, source, effective version and formula per field | Same name, different values; people memorise which one is “right” |
| Precedence | Last entry wins | Source-confidence order plus immutable snapshots | Agreement amounts overwritten by finance data; lineage breaks |
| Metric logic | Built around the current reporting template | Formula fixed first, numerator and denominator from one source | Metric decays into a manual spreadsheet within a year |
| Access control | Visibility scoped by role | Function, row and field level permissions | Deal-level cost and valuation visible laterally |
The number of reporting exits sets the depth of change
One organisation typically produces figures for several consumers at once: state-asset supervision, the finance authority, auditors, and internal management reporting. If the new system covers one exit, the rest keep their manual workaround, and total workload does not fall. It simply changes the shape of the export file.
Test this during selection: ask the vendor to draw the exit map in the room. For each exit, record the recipient, the template owner, frequency, the step that costs the most time today, and the module that will produce it after go-live. An organisation that cannot draw this map is not ready for commercial negotiation. It means the internal definition inventory is still incomplete.
Calculated metrics survive; entered metrics decay
We apply a single criterion: both the numerator and the denominator must come from objects that already exist in the system. Any metric that depends on extra manual entry turns into a table somebody has to maintain, and that maintenance always ranks below the current reporting deadline.
“Reporting cycle” should mean calendar days from the moment the supervisor issues the template to the moment the consolidated group submission leaves. It should not mean “filing feels smoother now.” “Definition consistency” should mean the share of a given metric whose value differs by zero across tiers, with district-level entities included in the sample. The full acceptance table appears in provincial SOE supervision consolidation.
Why demos almost always pass
Demos run on clean data: one legal entity, one fund, one reporting period, one standard template. Delivery deals with the dirty paths — two registry records for the same portfolio company, a sub-fund whose monthly report uses a different consolidation basis, a multi-currency fund that must pick one valuation currency. Replacing demo data with your own de-identified records is the highest-value move available at selection stage. It exposes the data model, the import tooling and the implementation team’s experience density in a single hour.
A checklist to bring into the selection meeting
- Supply de-identified real data (at least three deals, two reporting periods, one fund of funds) and require one end-to-end run from collection to submission.
- Ask for the field inventory: definition owner, source system and first effective date for every field.
- Draw the reporting exit map live, listing recipient, template owner and frequency for each line.
- Test field-level permissions with a finance account attempting to read a single deal’s cost field.
- Confirm deployment shape — public cloud, private cloud, fully intranet — and the domestic-stack compatibility scope, as a contractual term rather than meeting notes.
- Convert response commitments into breachable clauses. Our published service terms are 24/7 emergency response, problem localisation within one hour, and one year of free service after acceptance; each belongs in the contract.
- Require a written “out of scope” list and a phase-two boundary. Proposals without one defer risk to acceptance.
- Fix responsibility, effort estimation and rollback for legacy data cleaning and migration.
Three situations where we advise against starting
A single-fund general partner with roughly ten staff does not need a lifecycle platform; a shared document plus one controlled ledger is cheaper and answers external questions faster. An organisation whose budget covers only a base edition and assigns no data governance capacity should wait: that combination degrades inside two years, at a rate set by reporting frequency. And anyone expecting software to replace investment judgement should stop here — the system compresses evidence gathering, calculation and reconciliation, not accountability.
The final test is plain. Two years from now, when nobody remembers the original spreadsheets, will the numbers in the system still hold up? Feature lists drift with each release. Field definitions, reporting exits and metric formulas do not — provided they were written down and signed by the business, risk and reporting owners before the contract.