The need to efficiently ingest, validate, and mobilize data from operating partners is persistent and growing. GPs and LPs want richer, faster data, and incumbent technology is straining to keep up. Real assets is ripe for agentification. The question is who gets there first.
Three eras of real assets software
Real assets software has been built around one consumer at a time, in three eras. The first two are largely complete. The third is open. The combined entity is what consolidates Era One leadership with the substrate Era Three runs on.
Built to capture
Consumer: Finance, accounting, audit.
Architecture: ERP and systems of record.
Exemplars: Yardi, MRI, RealPage OneSite, Entrata, AppFolio. Captured transactions, enforced workflows, stored operational data. The system of record served the human reading the ledger.
Built to inform
Consumer: Analysts via BI and dashboards.
Architecture: Data warehouse, cloud SaaS, analytics.
Exemplars: Snowflake, Databricks, Cherre Connect, sector analytics platforms. Aggregated and presented data for human interpretation. The dashboard served the human reading the report.
Built to reason
Consumer: AI agents, autonomous workflows.
Architecture: Knowledge graph, context graph, decision graph.
Exemplars: Cherre Core, Cherre Alpha, Lumina, agentic platforms still forming. The substrate serves the agent. RealPage operates at Era One and reaches into Era Two. The acquisition consolidates Era One leadership with Era Three architecture.
The AI agent is not the next user. The agent is a different kind of consumer. It does not read reports; it reads data directly. It does not infer context from the conversation in the room; the context has to live in the architecture. It does not remember what was decided last quarter; the memory has to be queryable. Era Three software is what real assets architecture looks like when the consumer is the agent.
Three eras of real assets software, illustrative
Each era's advantage compresses as the next one opens. The combined entity sits at the Era Three inflection: an established Era One operator footprint (RealPage), the Era Two analytics layer that has not solved real assets at substrate depth, and the open Era Three substrate the acquisition is built to own.
The defensive case: reproducibility is the next audit standard
Audit committees, regulators, and IC processes are starting to ask a question they did not ask a few years ago: how was this decision made, by which model, against which version of which definition, with what supporting evidence. Today the question is answered with shrugs and post-hoc reconstructions. Within a short horizon the answer becomes an audit finding. The shift from "the report was correct" to "the reasoning was reproducible" is structural; it will not reverse with any administration's regulatory posture, because the fiduciary obligation driving it is older than the regulators. Institutions that cannot reproduce their AI-assisted decisions absorb the reproducibility gap as a fiduciary risk before it becomes a compliance one. The infrastructure that produces reproducibility is not the infrastructure that produces good dashboards. The two have been confused. They are not the same thing.
The agentic case is the opportunity. The reproducibility case is the risk. Both point to the same infrastructure.
"DSP and MDS provide a holistic, technology-forward capability that directly solves existing pain points, enabling GPs and LPs to take advantage of current and follow-on capabilities they continue to build internally."
The data mobilization gap
Operating partners generate the data. GPs and LPs need to consume it: quickly, accurately, and at scale. The gap between generation and consumption is filled today by manual processes, brittle spreadsheet pipelines, and point solutions that don't talk to each other. DSP and MDS are built to close this gap at the infrastructure layer.
Real assets is ripe for agentification
Industry leaders like Brookfield and Blackstone have already started the agentic journey. The rest of the market is catching up at varying levels of data and AI maturity. Firms that get their data infrastructure right now will be the ones who deploy AI meaningfully. Those that don't will be locked out when the window closes.
FDEs meet clients where they are
Forward Deployed Engineers offer readiness assessments, data engineering, agentic design and build, and optimization services. This is not a one-size-fits-all product play. It is a high-touch, expert-led capability that unlocks value at every point on the client maturity curve, from data clean-up to full agentic deployment.
The market maturity curve
| Maturity level | Where most firms are today | What they need from us | Entry product |
|---|---|---|---|
| Early, Data chaotic | Manual collection, fragmented systems, no single source of truth for fund data | Data mobilization, standardization, reliable pipeline from operating partners | DSP |
| Developing, Data structured | Data lives in systems but is not consistently validated, enriched, or governed | Ongoing management, QA, and enrichment at scale without internal headcount burden | MDS |
| Advanced, Data ready | Clean, structured data in place; executive pressure to get value from AI | Agentic use case design, deployment, and ongoing optimization | Agentic Platform |
| Leaders, AI native | Brookfield, Blackstone, actively building AI capabilities internally | Co-development, frontier capability deployment, optimization of existing agents | FDE Specialist Track |
Why this converges
- Data quality is the prerequisite for AI; firms cannot run reliable agents on bad data. DSP and MDS build the foundation that makes the Agentic Platform valuable.
- The product ladder is the growth model: land with DSP, expand to MDS, graduate to Agentic; each step increases switching cost and contract value.
- FDEs are the connective tissue; they are the reason clients move up the ladder rather than stalling at the first product.
- Real assets is underserved relative to other asset classes in both data infrastructure and AI tooling. First-mover advantage is real and the window is open now.
Two capability vectors, each with its own scaling path, talent model, and delivery engine. Vector 1 builds the FDE capability for AI. Vector 2 scales the deployment and support infrastructure for DSP and MDS. Together they form a closed loop: FDE drives adoption, DSP and MDS sustain it. Recommendation: Vector 1 is staffed from new hires in Q1; Vector 2 reorganizes existing Cherre and RealPage CX functions under unified leadership before the first EMEA pod is in market.
Forward Deployed Engineering for AI
Build and scale an FDE capability to support AI readiness assessments (where is the client on the maturity curve?), AI agent deployment (design, build, and go-live of agentic workflows), and client optimization of AI tools including ATLAS. FDEs are technical, embedded, and outcome-accountable. They are not a support function.
DSP Deployment & Managed Data Services
Scale a deployment and support capability for DSP that covers technical implementation (onboarding, integration, data pipeline setup) and ongoing support through Managed Data Services (MDS). This is the operational backbone that sustains the data quality clients depend on before and during AI deployment. MDS is the function where the combined entity inherits the largest asymmetry: Cherre delivers MDS through partner relationships rather than natively; RealPage owns a native MDS practice via the Hipercept acquisition, running from Bogota. Phase 01 work establishes Bogota as the in-house MDS anchor and rationalizes Cherre's partner relationships into a tiered surge and specialty surround.
Building sequence, what gets built first
- Define FDE hiring profile and 90-day ramp model
- Establish DSP onboarding playbook from existing deployments
- Launch MDS as a packaged, contractable service offering
- Run first AI readiness assessments with anchor clients
- Instrument the product ladder; track expansion signals from DSP clients
- Scale FDE team regionally (NA → EMEA)
- Productize the AI readiness assessment: fixed scope, repeatable output
- Build FDE for Agents specialist track with its own hiring and comp model
- DSP onboarding team at capacity; MDS support team established
- First EMEA fund admin channel relationships active
- APAC FDE presence (Singapore hub)
- Agentic Platform at scale across all ICP segments
- In-house DSP data engineering capability; partner model for niche sourcing only
- FDE as a durable competitive moat in every active market
- Cross-regional knowledge transfer cadence established
The vectors set the strategy. The stack is what the strategy has to install underneath. For thirty years the data layer of institutional capital was built around one consumer, the human reading a report. The reporting stack worked because the human did the integrating, interpreting, contextualizing, and remembering — invisibly, every time. The agentic stack does not have a human in that position. The cognitive work that always existed becomes a set of codified layers. Recommendation: the combined entity treats those codified layers as industry-level substrate, not enterprise-by-enterprise rebuilds; Section 10 sequences the deployment.
From the reporting stack to the agentic stack
Systems of record do not change. Storage does not change. The consumption layer does not change in role — its consumer does. What gets added are the layers that make explicit the cognitive work the human used to perform: entity resolution, knowledge representation, semantic interpretation, situational context, decision memory, and the reasoning surface that composes across them. Three classes carry through the stack. Persistent layers (01 and 09) carry across both eras unchanged; only the consumer of 09 expands. Transformed ingestion (02) keeps its mechanical transport but sheds the semantic arbitration that used to hide inside ETL. Codified layers (03 through 08) are what the human used to do invisibly, now made explicit because the agent has no head.
Read top-down: the consumer is layer 09; systems of record are layer 01. Click any row for the gap today and what is still missing at scale. The badge on each row carries two lenses at once — the architectural class (persistent, transformed, codified) and the delivery function in the combined entity. DSP owns the ingestion contract at layer 02. MDS owns the data-substrate codified layers (03–05): entity resolution, knowledge graph, semantic. FDE owns the reasoning codified layers (06–08): context, decision, reasoning surface. Layers 01 and 09 are client-owned.
Persistent 09 Action surface +
Was "Consumption." Same layer; the consumer expands from human to human + agent.
Consumers are display-shaped. Architecture assumes a human reading a chart; agents need graph traversal, semantic queries, lineage retrieval.
·
Codified · FDE 08 Reasoning surface +
Was implicit. The human composed across entity, relationship, definition, context, and memory to produce reasoning.
AI is bolted on. Models wrap around the dashboard. They see the outputs the human reads, not the substrate that produced them.
A reasoning surface agents can rely on. A stable interface that survives schema, vendor, and platform churn downstream.
Codified · FDE 07 Decision graph +
Was implicit. The human remembered what was decided last quarter and why it made sense.
No decision lineage. Approvals, overrides, sign-offs live in emails, chat, IC minutes. None of it structured or queryable.
A decision layer that is queryable. Capturing decisions as events with standard schemas is tractable. The reason it isn't solved is not technical. Operational and political.
Codified · FDE 06 Context graph +
Was implicit. The human held situational context: what was active when this happened, what definition was in force.
Context is reconstructed at query time. No native operation joins knowledge, events, and semantics; the work falls to whichever consumer asks the question.
A context graph that operates at population scale. Each firm's context graph stops at the firm's walls. The institutional memory worth having extends beyond any single firm.
Codified · MDS 05 Semantic layer +
Was scattered. Definitions lived in modeling code, BI tools, analyst heads, IC memos.
Semantic logic is scattered and unversioned. Same metric, multiple implementations. A definition active a year ago is not retrievable today.
A semantic registry that survives versioning. Today's semantic layers do not survive across tools, let alone across firms.
Codified · MDS 04 Knowledge graph +
Was the human's mental picture of how entities related.
The data is not graph-shaped. Real estate is a graph (entities and relationships) stored as tables. Multi-hop reasoning becomes expensive joins.
A canonical graph the industry agrees on. Each firm models its own; the graph of real estate itself does not exist at population scale.
Codified · MDS 03 Entity resolution +
Was implicit. The human reconciled "this building" across sources at query time.
No persistent canonical identity. Entity resolution happens at the BI or modeling layer, ad hoc, query by query. The same property has multiple IDs.
A canonical identity substrate every consumer trusts. Each firm builds its own, often poorly. No shared substrate exists at population scale.
Transformed · DSP 02 Ingestion + submission +
Was "Movement": ETL with semantic arbitration hidden inside it. The semantics extract to the codified layers above; the mechanical transport stays.
No event store. State changes are overwrites. The audit trail is "what was the value at month-end snapshot," not "what happened, when, why, in what order."
Schema-validated, append-only ingestion with row-level provenance. The layer as a contract surface, not a connector library.
Persistent 01 Systems of record +
Unchanged. Property management, fund accounting, valuation systems. The authoritative ledger for transactions in both eras.
·
·
The deployment question — what gets built inside the firm, what gets consumed from shared substrate, and the one layer that sits locally but depends on the substrate beneath — is answered in Section 10 Delivery, where the nine layers collapse into three deployment buckets.
Three products across three commercial models. Each serves a different point on the client maturity curve and generates a different type of revenue: recurring SaaS, data-as-a-service, and the emerging service-as-software model for agentic AI.
"The Agentic Platform is not Software as a Service. It is Service as Software. AI agents delivering outcomes that were previously produced by analyst teams and professional services organisations."
DSP, Data Submission Portal
The core platform for ingesting, validating, and mobilizing operating partner data for GPs and LPs. DSP solves the data pipeline reliability and quality problem at the infrastructure layer. It is the foundation on which MDS and the Agentic Platform sit. Priced as recurring SaaS; primary upsell vectors to MDS and Agentic.
MDS, Managed Data Services
Ongoing management, enrichment, and quality assurance of the data flowing through DSP. MDS is the service layer that sustains data quality over time, handling the complexity of operating partner data changes, new sources, and evolving schema. Priced as a managed service contract; high retention, high-margin recurring revenue.
Agentic Platform
AI agents that deliver outcomes previously produced by analyst teams. The Agentic Platform turns structured, MDS-managed data into working intelligence: automated reporting, anomaly detection, portfolio monitoring, and decision support. FDE-deployed and FDE-optimized. Value is measured in outcomes delivered, not software seats sold.
Product ladder, the land-and-expand model
| Stage | Product | Value delivered | Expansion trigger |
|---|---|---|---|
| Land | DSP | Reliable data pipeline from operating partners; single source of truth for fund data | Data volume grows or operating partner base expands. MDS conversation opens |
| Expand 1 | MDS | Data quality sustained at scale without internal headcount burden on the client | Client asks "what can we do with this data?" AI readiness signal is live |
| Expand 2 | Agentic Platform | AI agents producing portfolio analytics, investor reporting automation, anomaly detection | Agent outputs drive new use cases; cross-sell into adjacent data domains or asset classes |
| Optimize | FDE Ongoing | Continuous optimization of agents, new use case delivery, co-development on emerging capabilities | Sustained partnership. FDE embedded in client data and AI roadmap; highest retention |
Three regions, sequenced by market maturity, existing relationships, and go-live complexity. North America is the anchor. EMEA enters via the UK, with fund admin relationships in Luxembourg and the Netherlands as the continental wedge. APAC follows with Singapore and Australia as the entry points. Open question for RealPage: which EMEA fund admin relationships are in-flight today that should inform the sequencing of UK GM hiring?
- United States, primary market; deepest Cherre and RealPage relationships; existing AIM customer base anchors warm pipeline
- Canada, strong LP and pension fund concentration; CPPIB, OTPP, OMERS in ICP
- UK, London hub; GP and fund admin concentration; Phase 01 EMEA entry
- Germany, industrial real assets; open-end fund structures; DSP fit
- France, large institutional LP base; Axa IM, Amundi RE in ICP
- Luxembourg, fund domicile; fund admin is the entry channel
- Netherlands, pension LP concentration; APG, PGGM as anchor targets
- Singapore, regional hub; GIC, Temasek, sovereign wealth in ICP
- Australia, large superannuation funds; strong real assets allocation; AustralianSuper, QSuper in ICP
Entry model by market
| Market | Entry model | Regulatory / complexity note | Priority product |
|---|---|---|---|
| United States | Direct, existing team | Existing legal entity; no additional compliance burden for SaaS delivery | Full suite (DSP + MDS + Agentic) |
| UK | Direct, Phase 01 EMEA | English-first; UK GDPR compliance required; FCA considerations for financial data | DSP + MDS; Agentic in Phase 02 |
| Luxembourg / Netherlands | Fund admin channel | GDPR; fund domicile complexity; sell through existing fund admin relationships | MDS (fund admin-led) |
| Germany / France | Partner-assisted | Language complexity; local data sovereignty; GDPR Article 46 transfer rules | DSP; Agentic in Phase 03 |
| Singapore | Hub model, Phase 03 | MAS regulations; PDPA; data localization requirements growing | DSP + Agentic (sovereign wealth ICP) |
| Australia | Direct, Phase 03 | English-first; Privacy Act 1988; superannuation fund regulatory environment | MDS + Agentic (superannuation ICP) |
Four buyer archetypes, organized by position in the capital stack. Each archetype has a distinct door, buying motion, and conversion cadence. The Phase 01 anchor account (see Section 06) is a sovereign-scale LP engagement that brings 900 global operating partners into contact with a governed data substrate. Those 900 partners are the Phase 02 pipeline; each one is a GP, Asset Manager, or Operator in its own right, addressable through the substrate they already touch. The Institutional Asset Manager archetype is the primary direct-sales pipeline running concurrent with the anchor hub; the GP and Operator archetypes convert fast-cycle in parallel; mid-tier LPs follow as the LP archetype's broader pipeline from Phase 02. Warm pipeline from AIM, PRODA, Cherre, and RealPage customers is the channel into each archetype, not the archetype itself. Open question for RealPage: which institutional accounts in the existing RealPage book carry mandates that already require the substrate the combined entity provides?
| Buyer archetype | Door (primary product) | Buying signal | Buying motion | Conversion heat |
|---|---|---|---|---|
| Limited Partner Sovereign wealth, large public pensions, endowments, insurance allocations; GIC, Temasek, CPPIB, ADIA, NBIM as the leading edge. Cherre clients: OTPP, New York Life. In discussions: HOOPP. |
DSP and MDS; Agentic in long arc | CIO data commitment; manager rationalization; in-house data team build; cross-asset mandate | CIO-led, often by committee with Head of Investment Operations. Long cycle, large contract values, heavy governance. 12 to 18 month cycle for sovereign-scale; 18 to 24 months for mid-tier. | Highest for sovereign-scale Medium for mid-tier |
| General Partner Large real estate, infrastructure, and specialty sponsors; single-strategy or focused-platform firms below the multi-strategy mega-AM tier. Cherre clients: Starwood Capital, Savills IM. In discussions: Almanac (Neuberger Berman), QuadReal, PEC. |
DSP, ladder to MDS | Recent fund close above target; LP advisory pressure on reporting; growing operating partner base; fund admin RFP in flight | CFO-led. Faster cycle than Asset Manager. Less procurement weight. 3 to 6 month cycle. | High priority |
| Institutional Asset Manager Multi-strategy alternatives mega-firms; Brookfield, Blackstone, GIP, Stonepeak, Carlyle, Apollo, KKR, Ares, Macquarie, Nuveen as the archetype profile. Cherre clients: Brookfield, Nuveen, DWS, Sculptor (Rithm). In discussions: ICG. |
DSP and MDS, ladder to Agentic | Multiple operating partners; cross-asset portfolio; recent CDO or Head of AI hire; LP base demanding richer reporting | Multi-stakeholder. COO or CDO sponsored, CEO signature, CFO blessed. 6 to 12 month cycle. | Highest priority |
| Operator with institutional capital Greystar, AvalonBay, Equity Residential, Prologis, institutional-JV operators; RealPage's existing top-tier book |
Agentic Platform via Lumina; DSP if institutional sponsor agrees | Existing RealPage relationship; institutional ownership; visible AI initiative; operational data depth | COO-led. Fast cycle at the operating leadership level. 2 to 4 month cycle. | High priority for Agentic Medium for DSP/MDS |
The largest sovereigns and reserve funds are the leading edge of the LP archetype. They have internal data sophistication, cross-asset mandates by construction, and procurement capacity to commit to substrate-grade infrastructure. Mid-tier LPs follow the leading edge by 18 to 24 months. The Phase 01 anchor account (see Section 06) sits in this segment; the 900 operating partners that report into its governed data substrate become a directly addressable Phase 02 pipeline at the GP, Asset Manager, and Operator levels. The dual cadence inside the LP archetype is structural, not a sequencing choice.
A direct enterprise sales motion anchored in existing relationships, co-sold by FDEs who demonstrate technical value early in the cycle. The product ladder drives expansion: land with DSP, grow through MDS, graduate to Agentic. Fund administrators and real assets consultancies are the high-leverage channel partners. Recommendation: the FDE-led AI readiness assessment is the opening move in every Phase 01 sales cycle, productized to fixed scope and repeatable output before the first EMEA pod is hired.
Direct enterprise + FDE co-sell
AE owns the commercial relationship and pipeline. FDE engages early, often before a formal deal, to run a readiness assessment and demonstrate technical depth with the client's data and technology teams. The AI readiness assessment is the opening move: low-commitment for the client, high-signal for us, immediately differentiating.
Product ladder-driven land-and-expand
DSP is the land. MDS is the first expansion. Agentic is the graduation. Each step is triggered by a client signal: growing data volume, internal headcount pressure, or an executive asking "what can AI do for us?" AEs and FDEs must be trained to recognize and act on these signals before a competitor does.
Fund admins and consultants as multipliers
Fund administrators (who touch every one of their clients' data flows) and real assets consultancies are high-leverage channel partners. A single fund admin relationship can introduce DSP and MDS to their entire client base. Partner enablement requires patience and structure; the economics are compelling at scale.
Buyer map, who is in the room by product
| Buyer persona | Primary product | Core concern | Winning message |
|---|---|---|---|
| CTO / Head of Data | DSP, MDS | Pipeline reliability; reducing manual data work; integration complexity with operating partners | Medallion architecture; proven ingestion at scale; technical depth of FDE team demonstrated in assessment |
| CFO / Head of Finance | DSP, Agentic | Reporting accuracy; LP data requests at scale; audit trail and data provenance | Time saved on LP reporting; automation of existing manual reconciliation processes |
| Head of Portfolio Management | Agentic Platform | Faster portfolio insights; anomaly detection; decision support without adding analyst headcount | Agent demos with their own data; reference customers in the same vertical and asset class |
| Fund Administrator (ops) | DSP, MDS | Processing volume; client SLA fulfilment; reducing manual reconciliation and data cleaning | MDS managed service eliminates their reconciliation burden; channel economics for referrals |
| Managing Director / CIO | All products | Competitive positioning against peers; AI strategy credibility; board-level narrative on data and technology | Brookfield / Blackstone comparison; agentification as a competitive moat; FDE as the deployment proof point |
GTM sequencing, what opens the door
- Lead with the AI readiness assessment in every first meeting. It is low-commitment for the client, positions FDE expertise immediately, and surfaces the data gap that DSP solves
- Use existing AIM and PRODA relationships as the primary pipeline engine. These clients already trust the brand and have documented data pain points we can solve today
- Cherre and Realpage customer success teams must be trained to identify Agentic Platform expansion signals and route them to the Aphrodite AE team within 24 hours
- Establish fund admin partnerships with clear commercial structure, referral economics or co-sell model, before the first EMEA hire lands
- In EMEA, use the UK as the beachhead and Luxembourg / Netherlands fund admin relationships as the continental European wedge into LP accounts
Pipeline anchor, Phase 01 reference engagement
GIC
Stage: DSP and MDS, combined, in late-stage qualification. Product surface: data substrate platform plus managed data services across the institutional portfolio. Region: Singapore-led, global mandate. Buyer composition: committee-led with the Chief Operating Officer and the Head of Investment Operations as named champions. Operational depth: the engagement covers governance across 900 global operating partners.
GIC sits at the top of the capital stack and is one of the most operationally sophisticated institutional investors globally. The engagement proves three things at once. It proves that the Institutional Asset Manager and LP archetypes are commercially live for DSP and MDS in combination. It proves that the largest sovereigns are the leading edge of the LP archetype, ahead of the mid-tier LP cycle. And it proves the FDE co-development trajectory from Cohort 6: sovereign in-house builds run on top of the substrate Cherre governs, not against it.
Additional pipeline detail at the Asset Manager and GP archetype levels is referenced in the diligence data room.
The competitive map differs by region. In North America, incumbents are entrenched but not AI-native. In EMEA, eFront dominates fund management but lacks a managed data and agentic layer. APAC is the least mature and most open market. The integrated DSP + MDS + Agentic stack is the differentiator in every region.
Motivated competitors have the capital. They do not have the substrate or the window. The acquisition closes both.
The competitive landscape splits into structural cohorts that travel across regions. Operator ERPs (Cohort 1) and operator AI surfaces (Cohort 2) compete at the application layer. Institutional reporting platforms (Cohort 3) and analytics platforms (Cohort 4) compete at the data layer. Horizontal AI infrastructure (Cohort 5) competes through vertical acquisitions. Sovereign and institutional in-house builds (Cohort 6) are not competitors; they are the highest-value Portal accounts. Cherre's substrate position is at the layer that does not yet have an incumbent.
North America
| Competitor | Cohort | Their position today | Their motivated next move | Why we are ahead, and for how long |
|---|---|---|---|---|
| Yardi / MRI Software | Cohort 1: Operator ERP | Deep property management workflows; large installed base; growing AI investments (Yardi Virtuoso, MRI Agora) | Extending operational AI layer into adjacent workflows; partner acquisition for substrate gaps remains open | Operational AI is bounded by the data silo it sits on. We govern the substrate they would need to acquire. |
| Yardi Virtuoso, MRI Agora, Elise AI, Funnel Leasing | Cohort 2: Operator AI surface | AI products embedded in or alongside Cohort 1 systems. Resident communications, leasing, marketing automation. Funnel growing fastest in cross-platform leasing AI. | Vertical deepening by sub-segment (student housing, senior living, single-family rental); cross-platform extension | Lumina is the only AI in this cohort that runs on a governed substrate. Surface plus substrate is structurally different. |
| Juniper Square | Cohort 3: Institutional reporting | Strong LP reporting and fund admin portal; modern UX; growing EMEA presence; LP-centric data model | Extending into operator data aggregation; fund admin partnerships could carry them into the GP layer | Fund admin DNA is single-purpose. Multi-source operating partner aggregation is a different architectural problem. |
| Allvue / iLevel | Cohort 3: Institutional reporting | PE and private credit data aggregation; growing investor portal experience; broader alts focus than real assets | Real-assets-specific build or acquisition; agentic layer is a credible roadmap addition | Real assets depth is decade-compounding work, not feature work. Allvue would need to acquire it. |
| Altus Group, 73 Strings | Cohort 4: Analytics and valuation | Altus owns commercial real estate analytics and valuation tooling. 73 Strings is the AI-native challenger, with overlap into Mercatus on institutional reporting. Both consume data; neither governs it. | Vertical extension into adjacent asset classes; platform build remains open | Analytics layer consumes data, does not govern it. The architectural gap to platform is structural; the AI-native version of analytics does not change the layer. |
| Snowflake, Databricks, Palantir | Cohort 5: Horizontal AI infrastructure | Cross-industry data and AI infrastructure. Real-assets vertical motions through partner programs. Palantir closest in posture to combined entity (FDE practice, vertical depth). | Vertical acquisition. Snowflake or Databricks acquiring a Cherre-equivalent is the credible path. | The acquisition closes the most credible alternative pathway. The obvious target leaves the market. |
EMEA
| Competitor | Cohort | Their position today | Their motivated next move | Why we are ahead, and for how long |
|---|---|---|---|---|
| eFront (BlackRock) | Cohort 3: Institutional reporting | Dominant in PE / RE fund management; deep LP and GP workflows; BlackRock platform DNA at the parent level; Aladdin's AI capability available to the broader BlackRock data stack | The single most credible motivated builder. BlackRock has the capital, the AI capability through Aladdin, and the institutional distribution to build the substrate Cherre operates. | The substrate is a decade of compounding work. BlackRock's window to build is closing as institutional buyers commit to a governed layer. CORA participation accelerates the close. |
| Chronograph, 73 Strings | Cohort 3 + 4 hybrid | Portfolio monitoring and AI-native institutional analytics; growing EMEA footprint. 73 Strings is the AI-native version of portfolio monitoring, valuation, and LP reporting; overlaps Mercatus and Altus. | Real-assets-specific deepening; managed services or agentic capability via partnership or acquisition | Portfolio monitoring is a different layer from data substrate. AI-native does not change the layer. The architectural distance is real. |
| Mercatus (Charles River / State Street) | Cohort 3: Institutional reporting | Infrastructure and alternatives reporting; State Street institutional distribution; serves the LP and GP reporting workflow | Cross-asset deepening; AI-native overlay (where 73 Strings is the credible challenger) | Reports on data, does not govern it. The State Street platform breadth does not extend into substrate architecture. |
| Local fund admin tech | Cohort 3: Institutional reporting | Local market knowledge; deep fund admin workflow integration; relationship density in specific jurisdictions | Regional consolidation into broader platforms; partnership with global incumbents | Point solutions face a window-of-incorporation problem. We offer the platform layer they would need to build under. |
APAC
| Competitor | Cohort | Their position today | Why we are ahead, and for how long |
|---|---|---|---|
| Global incumbents (Yardi, MRI, eFront) | Cohorts 1, 3 | Present in APAC but NA / EMEA-centric focus; real assets depth not optimized for region; institutional buyer profile in APAC is structurally different from US/EMEA | APAC institutional capital is concentrated and multi-asset by mandate. We meet that buyer at the substrate layer; the incumbents meet them at the application layer they have already pulled away from. |
| Local data products | Adjacent | Local market data coverage (PropertyGuru, REA Group, listings platforms); different problem entirely from institutional data governance | Different layer of the data stack. They are not competitive at the institutional layer; the buyer does not confuse them with us. |
| Sovereign wealth internal builds | Cohort 6: Institutional in-house | GIC, Temasek, CPPIB building proprietary AI capability inside the institution; not buying from vendors as a default posture | Internal builds are captive by design. The FDE co-development model accelerates their internal build rather than competing with it; they become the highest-value Portal accounts, not competitors. |
Multiple credible standards exist for the real assets data landscape: RETTC/MITS, REDI, NCREIF, OSCRE, INREV, and others. None connects to the others without manual reconciliation, and manual reconciliation does not survive contact with AI agents. CORA, the Common Ontology for Real Assets, does not compete with the standards bodies; it operates at the layer above them. It performs two functions no individual body is structured to perform for itself or its peers: n-way correspondence across the full landscape and longitudinal drift tracking. CORA is the standard of standards. Cherre's substrate is its operational implementation. See coradata.org for the public initiative.
What the meta-layer codifies: the drift taxonomy
Standards do not sit still. They evolve under their own governance, in their own cadence, against their own audiences. The drift across them is not noise; it is the structural problem the meta-layer exists to solve. CORA names three drift types.
Structural drift
The schema reorganizes. Same concept, new shape. Mappings that relied on the prior structure break silently. Without a meta-layer that pins the prior structure and annotates the change, downstream agents inherit a broken dependency they cannot detect.
Semantic drift
A concept's definition narrows, broadens, or is redefined. The label stays the same; the meaning does not. Comparability across time degrades silently. The audit trail says "OperatingExpense" was reported in both periods; only the meta-layer records that the definition moved between them.
Coverage drift
The standard expands or contracts. The scope of what is covered changes. Whole-domain gaps appear in cross-standard reconciliation when one body extends into territory another has retreated from. The meta-layer is what makes the gap visible before downstream systems silently consume it.
CORA operationalizes the drift taxonomy as a drift register: a neutral, public, version-pinned, machine-readable record of where and when drift occurs across the full standards landscape. Each entry captures what changed, why it matters downstream, and traces back to source documents. The register is the citable artifact. Cherre's substrate is the operational implementation. The platform applies the n-way correspondence and the drift annotations in production so that an agent reasoning on top of it does not silently break when an underlying standard moves.
The bodies the meta-layer spans
Below the meta-layer sit the standards bodies the drift register tracks. Cherre is seated in the four most relevant to the combined entity's product portfolio.
RETTC
Cherre seated. The Real Estate Technology & Transformation Center owns the MITS (Multifamily Information Transaction Standards) data model and APIs, covering property marketing, leasing, screening, and transactions across multifamily rental housing. Operator-side, multifamily-only. Aligns to RP Core.
REDI
Cherre seated. The Real Estate Data Initiative is investor-led and produces a single data model that operationalizes existing standards (INREV, NCREIF) rather than replacing them. Covers closed-end, open-end (APAC, EU, NA), and SMA institutional vehicles. Aligns to DSP and AIM Core.
NCREIF
In active discussions. National Council of Real Estate Investment Fiduciaries; the Chart of Accounts initiative standardizes operating revenue and expense coding for institutional performance benchmarking and the NCREIF Property Index. LP-side benchmark. Aligns to DSP and AIM Core.
OSCRE
In active discussions. Open Standards Consortium for Real Estate; the Industry Data Model spans 130+ use cases and 1,000+ entities across operator and institutional real estate, with downloadable JSON and XML schemas. The broadest cross-segment model of the four.
The standards landscape maps cleanly onto Cherre's product cores. RP Core (multifamily, operator-side) sits where RETTC/MITS owns the rental-housing data exchange. DSP and AIM Core (LP, institutional) sit where REDI and NCREIF anchor the institutional reporting and benchmarking work. OSCRE spans both as the broadest cross-segment model. Cherre's seats are secured on the segment-specific bodies that mirror its product cores (RETTC on the operator side, REDI on the institutional side) and in discussion on the institutional benchmark (NCREIF) and the cross-segment model (OSCRE). Both halves of the product portfolio are already represented in the rooms where standards are being formed.
REDI's stated approach is to operationalize INREV and NCREIF rather than replace them. This is the same logic CORA codifies one layer up. The standards bodies that matter are already converging on the "connect existing standards, do not invent a new one" model. The structural risk a sophisticated diligence team will look for is whether a vendor-neutral standard could emerge that commoditizes the semantic layer. The answer reverses the question. Cherre is not a participant in the standards being commoditized. Cherre operates the layer above them: the n-way correspondence, the drift register, the operational implementation of the meta-layer. The firm that implements the meta-layer is not displaced by the standards converging beneath it. The firm that implements the meta-layer is the firm the convergence runs through.
Cherre is not a participant in the standards. Cherre is the operational layer above them.
Three delivery functions, each mapped to a product. The Onboarding team deploys DSP. The Support team sustains MDS. Forward Deployed Engineers build and optimize the Agentic Platform. The Medallion data architecture, Bronze, Silver, Gold, is the shared development methodology that underpins all three functions. Recommendation: the Onboarding team is built from Cherre's existing DSP deployment muscle plus RealPage's implementation team; the MDS Support team is stood up new under unified CX leadership; FDE is hired against a defined pod profile.
Onboarding Team
Responsible for technical implementation of DSP: data source discovery, connector setup, schema mapping, validation rule configuration, and go-live. Onboarding velocity, time from contract signature to first live data, is the primary metric. Playbooks are standardized globally; client-specific configuration is documented and handed to MDS on go-live.
Support Team
Manages ongoing data quality, pipeline reliability, and issue resolution for MDS clients. This is not a helpdesk. It is a managed service organization accountable to data quality SLAs. It handles operating partner data changes, schema drift, new source onboarding within existing contracts, and platform-level escalations to DSP engineering. The post-close MDS practice runs from a single in-house anchor: RealPage's Hipercept-acquired Bogota operation. Cherre's existing MDS partner network supplements this anchor with surge capacity and specialty coverage where Bogota's playbooks have not yet been built.
Forward Deployed Engineers
FDEs design, build, and optimize AI agents for clients. They begin with a readiness assessment (is the client's data ready?), move to use case design (what should the agent do and why?), then build and deployment. Post-deployment, FDEs optimize agent performance and identify the next use case. They are the expansion engine for the Agentic Platform contract.
Why FDE-shaped delivery, not Center of Excellence
A Center of Excellence holds capability centrally and routes domain requests up for review before outputs return to the field. The model scales for reporting-era outputs, where review cadence is weekly and approval latency is measured in business days. Agentic outputs are continuous. Approval chains become latency. The reviewing center becomes the bottleneck the agent was supposed to eliminate. FDE-shaped delivery keeps domain expertise and AI capability in the same accountable unit. Pods carry the governing principles into the engagement. Authority sits at the unit doing the work. The decision-maker receives governed outputs without the relay.
Approval chains were a feature in the reporting era. They are a bottleneck in the reasoning era.
The model has institutional precedent. Palantir's Forward Deployed Engineer practice scales by pod, not by hierarchy. McKinsey's QuantumBlack operates as embedded teams with platform-side principals, not as a center of excellence routing through a partnership. The argument is not that FDE is new; it is that the existing CoE-shaped CX functions inside both Cherre and RealPage need restructuring before they meet agentic delivery at scale.
Capability model, who owns what
| Capability | Onboarding team | MDS support team | FDE |
|---|---|---|---|
| Data source discovery & schema mapping | Owns | New sources in-contract | Complex / novel schemas |
| Connector setup & pipeline configuration | Owns | Maintains post-go-live | Custom / bespoke integrations |
| Ongoing data quality & SLA management | Hands off at go-live | Owns | – |
| AI readiness assessment | – | – | Owns |
| Agent design, build & deployment | – | – | Owns |
| Agent optimization & new use case expansion | – | – | Owns |
| Client technical training & enablement | DSP-level | MDS-level | Agentic-level |
| Platform bug escalation to product engineering | Escalates | Escalates | Escalates + provides field context |
Build, buy, or consume: the architectural layers
The in-house vs. partner question is sharper at the layer level than at the function level. Some layers each enterprise has to run for itself. Some are candidates for shared industry-level infrastructure, because the value of each scales with the number of participants. One layer sits locally but depends on the layers below being stable. This is the framework the combined entity uses to answer the audience's question about which services stay in-house and what in-house actually looks like.
Operated inside the firm
Layers: Systems of record, ingestion, consumption surface. Why: these reflect firm-specific operating models, security perimeters, and consumer surfaces. Each client owns them. RealPage owns at the operator side; Cherre owns at the institutional side. The post-close question is consolidation and standards, not provenance.
Shared infrastructure
Layers: entity resolution, knowledge graph, semantic layer, context graph, decision graph. Why: the value of each scales with the number of participants. A canonical identity layer with one institution's data is worth less than one with many. This is the layer the combined entity operates for the industry. CORA codifies the coordination; the platform implements it.
The reasoning surface
Layers: reasoning surface, agent workflows. Why: each client deploys agents against their own use cases, but those agents query a stable model-context surface that abstracts them from underlying schema and vendor changes. FDE-shaped delivery is what makes this layer reliable across clients without bespoke point-to-point integration.
The nine layers, mapped to the three buckets
The architecture defined in Section 03 collapses here into a deployment decision. Each row is one layer of the stack; the bucket column names where the combined entity operates it — built or bought inside the firm, consumed from shared substrate, or sitting locally but depending on the substrate beneath.
| # | Layer | Class | Bucket |
|---|---|---|---|
| 09 | Action surface (consumption) | Persistent · consumer expands to human + agent | Enterprise · build or buy |
| 08 | Reasoning surface | Codified · FDE | Local but dependent |
| 07 | Decision graph | Codified · FDE | Industry · consume |
| 06 | Context graph | Codified · FDE | Industry · consume |
| 05 | Semantic layer | Codified · MDS | Industry · consume |
| 04 | Knowledge graph | Codified · MDS | Industry · consume |
| 03 | Entity resolution | Codified · MDS | Industry · consume |
| 02 | Ingestion + submission | Transformed · DSP | Enterprise · build or buy |
| 01 | Systems of record | Persistent | Enterprise · build or buy |
The audience flagged that existing deployment and CX functions are weak in both legacy organizations. The layer-level frame is the answer: the substrate (industry-level) is where the combined entity invests deepest, because that is where scale advantage compounds. Enterprise-side delivery (in-house implementation, MDS support, FDE pods) is rebuilt under the Professional Services BU. RealPage's Hipercept-acquired Bogota MDS practice is the in-house anchor for the support function; Cherre's MDS partner network rationalizes into a tiered surround for surge and specialty coverage. Partner participation is appropriate at the enterprise edges (regional implementation surge capacity, jurisdiction-specific compliance, MDS surround) and explicitly inappropriate at the substrate.
Medallion architecture, the shared development methodology
The Medallion architecture defines how data is ingested, validated, and made ready for AI, in three enforced layers. Every client deployment follows this pattern, which ensures data quality gates are met before AI agents operate on the data. It is the shared methodology across Onboarding, MDS, and FDE.
- Operating partner data ingested as-is; no transformation at point of entry
- All source formats supported: structured, semi-structured, document
- Full audit trail maintained from source to destination from day one
- Schema discovery and initial data profiling run automatically
- Data lineage tracked continuously; source attribution preserved
- Schema normalization and field mapping to client data model
- Deduplication and entity resolution across operating partners
- Validation rules applied (defined per client by MDS team)
- Anomaly flagging and exception reporting generated automatically
- Cross-source reconciliation and conflict resolution
- Enriched, analytics-ready data sets available for downstream consumption
- API-consumable for client systems, dashboards, and reporting tools
- Structured for agent consumption: embeddings, retrieval, context packaging
- Portfolio analytics and LP reporting outputs generated at this layer
- FDE-built agent workflows operate exclusively at the Gold layer
Beyond Gold: the decision graph
The Medallion layers serve the data agents reason against. The decision graph is what makes their reasoning auditable. Every meaningful action an agent takes, every approval, every override, every interpretation, every model output, is captured as a queryable event indexed by entity, by actor, by time, and by definition version. This is what reproducibility looks like in implementation. Without it, an agent that produces the right answer cannot prove how it produced the right answer, and the answer fails the audit standard the next era will impose.
The Gold layer makes the agent capable. The decision graph makes the agent accountable.
Delivery model decisions to resolve
- Define the handoff protocol between Onboarding and MDS: documentation requirements, SLA definitions, and client introduction process must be standardized before the first EMEA hire
- Productize the FDE readiness assessment: fixed scope, defined output format, repeatable methodology across all ICP segments; this is the opening move in every sales cycle
- Determine the staffing ratio between Onboarding, MDS, and FDE by region and phase. These ratios drive the hiring plan and budget model
- Build Bronze → Silver → Gold quality gate definitions into the DSP platform so they are enforced by the system, not by manual process dependent on individual team members
- Define "agent-ready" data specifications per ICP segment. The Gold layer configuration differs between a GP, an LP, and a fund administrator; FDEs and Onboarding must align on this before Phase 02
The combined entity stands up three organizational moves at close: a Professional Services BU with separate P&L from the software business, an FDE Practice inside that BU, and a unified Customer Experience function spanning Onboarding, MDS Support, and FDE. The structure is designed for the operating model the next eighteen months require, not the one inherited from either firm. Recommendation: stand up the Pro Services BU first; do not absorb existing teams unchanged.
Professional Services BU
Stand up the Professional Services function as a separately governed business unit inside the combined entity, with its own P&L, GM, and operating cadence. The BU runs Onboarding, MDS Support, and FDE under unified leadership but with delivery functions reporting through the BU rather than into the product organization. This separates services economics from software economics and preserves the integrity of both.
FDE Practice
The FDE Practice sits inside the Professional Services BU and is structured as a federation of small embedded pods, each carrying domain expertise and AI capability in the same unit. Authority sits at the pod. Coordination across pods is lateral. The Practice ramps regionally on the same phase-gated sequence as the rest of the BU, with the NA cohort hired first and EMEA following at the Phase 02 gate.
Unified Customer Experience
The CX function is built fresh, not inherited. Onboarding, MDS Support, and FDE share a single intake, a single client success owner per account, and a single escalation path back to product engineering. This is the function the audience flagged as weakest in the existing organizations; the brief recommends rebuilding it rather than merging the existing teams.
Capability map, what gets merged, what gets built, what gets sunset
| Capability | RealPage today | Cherre today | Post-close action |
|---|---|---|---|
| Implementation / Onboarding (operator data) | Owns at scale | DSP-specific muscle | Merge under Professional Services BU; RealPage muscle leads, Cherre DSP expertise embeds |
| Implementation / Onboarding (institutional data) | – | Owns | Cherre team carries forward; reports into Professional Services BU |
| Managed Data Services (MDS) | Established native practice via Hipercept (Bogota nearshore) | Partner-delivered, not native | Bogota becomes the in-house MDS anchor; Cherre's partner ecosystem rationalized into tiered surge and specialty surround; new hires staffed against EMEA / APAC ramp |
| FDE for Agents | – | Early-stage practice | Build new under FDE Practice; structured hiring against named ramp profile |
| Customer Success (operator accounts) | Owns at scale | – | Restructure under unified CX function; not absorbed unchanged |
| Customer Success (institutional accounts) | – | Owns | Cherre team carries forward; institutional-only CS specialization preserved |
| Sales engineering / Solutions consulting | Owns | Solutions function | Open question, merge under sales, or fold into FDE pre-sales motion |
| Partner / channel enablement | Partial coverage | Fund admin channel only | Open question, channel strategy precedes org design here |
Hiring sequence, what gets staffed first
- Professional Services BU GM hired (external or elevated from Cherre senior team)
- Unified CX function lead identified and given mandate for cross-function integration
- NA FDE Practice lead hired against defined pod profile
- First two regional pod members hired into NA; remaining ramp follows phase gate
- Bogota MDS practice (RealPage via Hipercept) consolidated as in-house anchor; Cherre's MDS partner relationships rationalized into tiered surge/specialty surround; capacity plan finalized against Phase 01 deal pipeline
- EMEA Pro Services BU lead in market (UK based); first EMEA FDE pod ramping
- FDE Practice scales to defined NA cohort target; productized AI readiness assessment in market
- MDS Support regional team established in EMEA
- Unified CX function fully merged across legacy RealPage and Cherre teams
- FDE comp model and attribution rules finalized; first cross-region FDE deployment executed
- APAC presence stood up (Singapore-led, Australia secondary)
- FDE Practice scales to durable global headcount with cross-region rotation
- Partner ecosystem operational at target ratio of in-house to channel delivery
- Unified CX function operating at steady state across three regions
- Pro Services BU P&L at defined contribution to combined entity revenue
Organizational decisions to resolve before close
- Confirm the Professional Services BU GM reports to the CEO of the combined entity, not into the software P&L; this separation is the precondition for credible services economics
- Define the FDE Practice's relationship to product engineering; is FDE a customer of product, a peer to product, or a feedback channel into product roadmap? The choice determines pod composition and hiring profile
- Finalize whether the CX function leads from operator side (RealPage muscle) or institutional side (Cherre depth); the answer drives whether the existing RealPage CX team is restructured or partially replaced
- Resolve the open questions in the capability map, solutions engineering merge path, and channel-partner strategy, before regional hiring for Phase 02 begins
- Establish FDE attribution rules between sales (deal credit) and Practice (deployment outcome) before the first regional FDE is hired; cross-region FDE deployments need an explicit attribution policy at hire
- Decide the FDE compensation model; pod-level deployment target, deal-attach component, NRR contribution, or hybrid; the model has implications for how pods coordinate vs. compete
Three functions. Distinct scope. No overlap on accountability. The capability model defines what Onboarding, MDS Support, and FDE each own, where they support each other, and where their mandate ends. It is the operational answer to what the combined entity actually delivers — and the frame against which every hire, every ramp, and every client engagement is evaluated.
Onboarding
Purpose: Get the client's data to a certified Gold-layer state, on schedule, with a documented handoff. Onboarding owns everything from first kickoff to go-live sign-off. Its success metric is time-to-Gold.
Scope limit: Onboarding ends at go-live. Post-go-live data quality and pipeline health transfer fully to MDS Support. Onboarding does not maintain; it delivers and moves.
MDS Support
Purpose: Maintain the Gold-layer state Onboarding delivered, continuously, against agreed SLAs. MDS Support owns data quality post-go-live, pipeline reliability, and operating partner change management. Its success metric is SLA attainment and anomaly resolution time.
Scope limit: MDS Support does not onboard new clients; it manages within active contracts. Net-new client onboarding returns to the Onboarding function.
Forward Deployed Engineering
Purpose: Design, build, and optimize AI agents that operate on Gold-layer data. FDE owns the full agent lifecycle — from readiness assessment through deployment and ongoing optimization. Its success metric is deployed agent count, agent NRR, and new use case expansion per account.
Scope limit: FDE does not do data engineering or pipeline management. It operates on a stable data layer. If the layer is not stable, FDE surfaces that to MDS and Onboarding before proceeding.
Onboarding delivers a state. MDS defends that state. FDE builds on top of it.
Capability model
Functional areas define the phases of delivery. Capabilities (pills) will be mapped to each area and color-coded by which function owns them — Onboarding, MDS Support, or FDE. Project Management spans all four delivery phases as a cross-cutting discipline.
Maturity levels — baseline to excellent
Baseline is the floor — what each function must be able to do before touching a client account. Excellent is the Phase 02 target state. The gap between them is the development agenda for each function lead.
| Function | Baseline (floor at hire) | Excellent (Phase 02 target) |
|---|---|---|
| Onboarding | Executes documented onboarding playbook; achieves Bronze and Silver layer certification within committed timeline; completes clean MDS handoff with documented validation ruleset | Runs parallel onboarding tracks without quality degradation; proactively surfaces schema complexity before kickoff; contributes new patterns to playbook; zero regression on MDS handoffs; sub-30-day time-to-Silver for standard ICP clients |
| MDS Support | Monitors pipeline health against SLA thresholds; resolves data quality exceptions within agreed window; manages within-contract source additions without re-engaging Onboarding for playbook guidance | Predictive anomaly detection — surfaces issues before clients flag them; owns schema drift taxonomy and responds to regulatory changes without escalation; SLA attainment above 99%; maintains Gold-layer readiness for FDE without manual coordination; monthly data quality report published to client stakeholders |
| FDE | Delivers productized AI readiness assessment; scopes and deploys first agent against a defined use case within agreed timeline; achieves client acceptance on first submission | Runs multi-use-case agent programs across concurrent accounts; proactively identifies expansion use cases before renewal; contributes reusable patterns to FDE practice library; generates measurable NRR lift on every covered account; deployable cross-region without a re-ramp period |
Ramp model — 30 / 60 / 90 day milestones
Every new hire enters a structured ramp regardless of seniority. Milestones are binary — either the deliverable exists or it does not. They are the basis for ramp-period performance review and the gate before a hire receives primary account ownership.
Onboarding
- DSP platform certified — can configure connectors, run schema mapping, execute Bronze ingestion independently
- Onboarding playbook read; can reproduce the go-live checklist without reference
- Has shadowed at least one full engagement from kickoff to MDS handoff
- Can explain the Silver validation ruleset framework to a client without support
- Co-lead on at least one live onboarding engagement
- Has identified and documented at least one schema edge case not covered by existing playbook
- Completed first MDS handoff with no playbook gap flagged by the receiving team
- Handling day-to-day client communication on onboarding status independently
- Primary lead on one or more engagements end-to-end
- Time-to-Silver tracking within 10% of team average
- At least one new pattern or edge case contributed to shared playbook
- MDS handoff accepted on first submission — no rework required
MDS Support
- Monitoring tooling certified — can independently read pipeline health dashboards, exception queues, and SLA tracking
- Has shadowed at least three exception resolution cycles with a senior team member
- Understands SLA definitions for all active accounts in assigned portfolio
- Knows the escalation path to Onboarding (new sources) and Product Engineering (platform bugs)
- Primary owner of a defined portfolio of MDS accounts under supervision
- Resolving anomalies and exceptions independently within agreed SLA windows
- Has handled at least one within-contract new source addition end-to-end
- Weekly SLA report produced accurately and on schedule for assigned accounts
- Unsupervised portfolio ownership; SLA attainment at or above team average
- Has triaged at least one schema drift event without escalation to Onboarding
- Proactively flagging data quality risks before clients report them
- FDE team receiving Gold-layer data without manual coordination
Forward Deployed Engineering
- ATLAS platform certified — can configure, deploy, and test agent workflows in sandbox
- AI readiness assessment framework internalised; can deliver it independently on a practice account
- Has reviewed at least two completed FDE engagement case studies end-to-end
- Domain context established — understands the real assets operating model for their assigned ICP segment (GP, LP, Operator, or Institutional Asset Manager)
- Co-lead on at least one live FDE engagement; has run the readiness assessment with a real client
- First agent use case scoped, designed, and approved by client stakeholder
- Agent deployed to Gold-layer data in client environment; acceptance criteria met
- Has coordinated at least once with MDS Support on a Gold-layer data question and resolved without escalation
- Primary FDE lead on at least one account; managing the readiness → build → deploy → optimize cycle independently
- First expansion use case identified and in scoping with client; NRR motion active
- At least one reusable agent component or use case pattern contributed to the FDE practice library
- Can represent the FDE function credibly in a sales cycle — readiness assessment as the opening play
A ramp milestone is not a check-in. It is a binary gate. Either the deliverable exists or it does not.
Capability model decisions to resolve
- Define the formal handoff document template between Onboarding and MDS Support before the first EMEA hire joins — the handoff protocol cannot be verbal at regional scale
- Productize the FDE AI readiness assessment: fixed scope, defined deliverable format, consistent pricing — this is the opening play in every Agentic Platform sales cycle and must be repeatable across all pods
- Establish the Gold-layer readiness specification per ICP segment (GP, LP, Institutional Asset Manager, Operator) so Onboarding and FDE share a definition before Phase 02 hiring begins
- Decide whether MDS Support and Onboarding share a team lead or report separately into the Pro Services BU GM — the answer changes the escalation path and the career ladder for both functions
- Build the 30/60/90 ramp milestones into the offer letter and day-one onboarding for every hire — not as aspirational targets but as the explicit condition for ramp-period completion and transition to full OTE