Capability notes — Portfolio Engine and MCRM

1. Portfolio Engine (PE)

Destination (PE's own handover): a research, portfolio construction, review and intelligence engine. Workflow: objective → rules → universe → research → selection → weights → portfolio → backtest → comparison → report; and for a client: client portfolio → review → actions → alternative portfolio → objective-based backtest → report. Mutual funds are the first slice; ULIP and multi-product follow.

What exists on main (code, tested)

Area	Capability	Main modules
Data in	Thin client for 3 endpoints (/api/schemes, /api/scheme/nav, /api/index/nav), base URL switchable to stgapi; normalisation of every known API defect (types, duplicates, order, index identity); full-pull snapshot cache	data/moneymarche_client.py, data/normalize.py, data/cache.py
Reproducibility	Every result carries provenance (snapshot, as-of, methodology version, config, formula)	provenance.py
Fund research	Fact sheet, scorecard, comparison, category peers, category benchmarks, IDCW total return, AMFI dividends, return/CAGR and risk-ratio reconciliation against AMC factsheets	fund_fact_sheet.py, fund_scorecard.py, fund_comparison.py, category_*, idcw.py, phase1d_*
Selection	Rule-based fund selection, investment taxonomy	fund_selection.py, investment_taxonomy.py, taxonomy_dimensions.py
Portfolio	Definition, strategy engine, rule-based construction, representative portfolios	portfolio_definition.py, strategy_engine.py, rule_based_portfolio_construction.py
Accounting	Transaction ledger → exact-date valuation → value series → return series; XIRR from cashflows	transaction_ledger.py, daily_valuation.py, valuation_series.py, cashflow_returns.py
Backtest and dynamics	Backtesting, dynamic portfolio replay, drift-triggered rebalance, multi-date drift monitoring	portfolio_backtesting.py, dynamic_portfolio_replay.py, drift_triggered_rebalance.py, multi_date_drift_monitor.py
Review and reports	Portfolio comparison, portfolio review, client portfolio review; Markdown, JSON and Excel reports	portfolio_comparison*.py, portfolio_review*.py, client_portfolio_review.py, *_excel.py
Demo	Small web app (webapp.py, cgi-bin/index.py), Phase 2 fixture demo	tools/phase2_demo.py

Evidence base: an approved 25-fund HDFC+ICICI test universe (not the product universe), 252-day annualisation, 10Y G-Sec 7.067% as risk-free proxy, no approved portfolio benchmark.

What is being built (open PRs and issues)

• Objective-based fund selection (PR #321, issue #315; CI green on 11 Oct) — the active implementation.
• Client portfolio review Excel workbook (PR #310, issue #309); category/universe/benchmark plan (PR #314, issue #313).
• Product and reporting architecture docs (PRs #312, #275, #249, #247), agent handover (#311).
• About 29 open PRs in total, many from mid-September (Phase 1 universe evidence #184–#212, #236–#245) that look superseded: a clean-up like GOV-1 is due.

Where PE stands with the API

• Uses production api.moneymarche.com by default; stgapi validation (Release B) was never executed live — PE's environment could not reach stgapi, and stgapi had no data.
• PE decided (Gateway resilience assessment) not to build a second ingestion path: the existing client + normalise + cache is the Gateway boundary until a real new data defect appears.
• Upstream gates PE needs from API/MM-Cron (Phase 3 readiness doc): authoritative NAV writer, stable scheme identity and lifecycle, NAV date semantics, validity, duplicate rules, freshness, historical access, verified route contract. These are a ready-made requirement list for API M2.

Deployment

• GitHub Actions CI (hosted runners) works for PRs. A manual Bluehost deploy workflow exists (immutable releases under the arevalif account, snapshot cache outside releases); a Pages demo workflow exists.
• Atul (14 Oct): Bluehost and GitHub-hosted runs were tried, then the laptop; Claude CLI was used for testing and burnt Claude credits. Need: CI plus a desktop runner, without Claude CLI.

2. MCRM

Status: design finalisation; no code — documentation and research only.

What exists

• Strategic, scope, design, current-state, architecture and roadmap documents (authority hierarchy 00–05), Waves 0–6 for CRM Phase 1 (Stabilise → Party/Identity/KYC → Dossier → Sales → Documents → Integration → Operations).
• Level-1 CRM API contract, data model/ERD, security/identity architecture, SoR and data ownership.
• Product Knowledge research JSON (12 Oct): Health, Term and Motor each with identity, version, variant, configuration space, coverage, benefit, add-on, rule, economics, service capability, provenance; cross-category category tree, calculator capability matrix, rate-table archetypes, provider ranking framework.
• October plan (MC-0 approved): WP1 website/API catalogue contract and category tree; WP2 non-MF identity/version evidence; WP3 MF family/variant model.

What is being built

• WP1 category tree proposal (issue #103) — the current step; WP2 (#104), WP3 (#105), WPDev compatibility stream (#96).
• About 29 open documentation PRs (#64–#101) against a limit of 5.

3. What each can offer other projects now

Project	Can answer / supply	For whom
PE	NAV data-quality rules (its normaliser lists every known API defect); factsheet/return/risk calculations reconciled to AMC factsheets; the upstream gate list	API/MM-Cron (requirements), MWMC (factsheet and fund pages)
MCRM	Category tree and product model; calculator inventory (from the staging website repo); Health/Term/Motor product knowledge	MWMC (categories, calculators, insurance pages), API (catalogue contract)

4. Observations for MMDEP

1. Both projects are rich in documents and PRs but light on things a user can see. PE has real, tested capability; MCRM has none in code yet.
2. Both need a PR clean-up (about 29 open each).
3. PE's stgapi work stopped because stgapi had no data; that is an MM-Cron job (copy production data into the staging database, then keep it current), not a PE task.
4. PE's best "nobody waits" work while upstream gates are open: objective selection (#321), client portfolio review, reports from code instead of Excel — all can run on the cached snapshot.