Skip to content

Upstream findings

Defects and surprises in the FINOS sources discovered while vendoring them, verified on 2026-09-04. The finos-mcp servers work around every one of them and pin the current behaviour in tests, so an upstream fix shows up as a test diff on the next sync.

Finding 1 was fixed upstream on October 21, 2026: issue #378 and merged PR #380. The current vendored AIGF snapshot includes that fix, and tests expect zero unresolved external references. The rest are candidates; outreach/README.md tracks which have been filed (finding 15 is finos/FDC3#2270) and why the others have not.

AI Governance Framework (finos/ai-governance-framework)

  1. Fixed in upstream PR #380: eight risk files formerly lost their related_risks list to a YAML comment. In docs/_risks/ the last uk-regulations_references entry's inline # comment has no newline before the following related_risks: key, so YAML folds the key into the comment and the stray ri-N tokens land in uk-regulations_references as bogus reference keys (19 unresolvable references). Files: the seven risks whose parser test entry lists uk-regulations keys of the form ri-N. Fix: a newline. Pinned in servers/aigf/tests/test_parser.py as EXPECTED_UNRESOLVED_REFS on the older snapshot; the current pin is empty after the upstream fix.
  2. docs/_data/references/ holds 13 datasets plus a README.md; documentation elsewhere counts 14.

Common Domain Model (finos/common-domain-model, Maven cdm-json-schema)

These were found against CDM 7.2.0 and 6.27.0 and are written as observed then. The vendored content moved to 7.4.0 and 6.29.0 on 2026-10-04 and to 7.5.0 on 2026-10-05. The current primary schema is 7.8.0 and the legacy schema is 6.30.0, both sourced from the official Maven Central releases on 2026-10-25. Known issues remain covered by pinned tests; if an upstream fix changes behavior, update the corresponding finding and assertion together. Finding 9 concerns the finos-cdm 7.2.0 package and was not re-tested.

  1. Rosetta basic-type names leak into JSON Schema type. Eight 7.2.0 schema files emit {"type": "BusinessCenter"} or {"type": "NonNegativeNumber"}, which are not JSON Schema types and no schema file defines them; a strict Draft 4 validator raises UnknownType. Worked around at load time by dropping the bogus keyword. Generator: REGnosys/rosetta-code-generators json-schema.
  2. Two 7.2.0 enum schema files contain raw control characters in descriptions (cdm-legaldocumentation-csa-CollateralAssetDefinitionsEnum, cdm-product-collateral-RatingPriorityResolutionEnum); strict JSON parsers reject them.
  3. Non-standard $anchor at the top level of every schema file (used to carry the namespace). Harmless to Draft 4 but stripped for cleanliness.
  4. The published schema and the published samples disagree on required fields. Against cdm-json-schema 7.2.0, 18 of 28 official 7.2.0 *-func-output.json samples fail only on required (ClosedState.activityDate, executionDetails, underlier, dateAdjustments, exerciseNoticeGiver). Either the schema over-declares cardinality relative to the Rune source, or the samples are not fully populated. Pinned in servers/cdm/tests/test_server.py (EXPECTED_VALID, EXPECTED_REQUIRED_MISSES).
  5. cdm-json-schema-6.27.0.zip on Maven Central is a gzipped tar, not a zip, despite the extension and application/zip content type. The sync script detects the magic bytes.
  6. The JSON Schema models the legacy JSON shape only. CDM 7 documents use the Rune JSON shape (@type, @key, @ref, @scheme/@data) and cannot be validated with the published schema as-is. finos-mcp normalises Rune JSON into the legacy shape, directed by the schema, before validating. A Rune-shape JSON Schema would remove the need.
  7. finos-cdm 7.2.0 on PyPI is not usable as a validator. Importing a model module directly raises a circular ImportError through the lazy finos._bundle; importing the bundle first takes about four minutes on a warm cache; and BusinessEvent.rune_deserialize then rejects CDM's own 7.2.0 samples with Input should be None on typed fields (instruction[].primitiveInstruction.split, after[].trade), which suggests field annotations resolve to None in the generated models. finos-mcp therefore does not depend on it.
  8. One legacy 6.27.0 sample contains a raw control character and needs lenient JSON parsing.

FDC3 (finos/FDC3)

  1. The intent-to-context mapping is not machine-readable. It exists only as ## Possible Contexts bullet lists in website/docs/intents/ref/*.md; Intents.ts and standard intents.json carry names only. finos-mcp generates intents.json from the markdown with a drift test. A checked-in JSON table upstream would help every consumer.
  2. fdc3.action references the API schema package. action.schema.json $refs ../api/api.schema.json#/definitions/AppIdentifier, so the context schemas are not self-contained; validating an fdc3.action needs the API schemas too. Reported as a structured reference issue.
  3. security.user.schema.json has an $id ending in user.schema.json, unlike every other file whose $id matches its filename (main branch only).
  4. Public claims that FDC3 3.0 "adds MCP integration" are not reflected in the repository or the 3.0 announcement; 3.0 is at 3.0.0-alpha.2.
  5. StartChat and SendChatMessage return a chat room only in their example code. Both reference pages read const chatRoom = ... getResult() in the example, but neither declares a result the way ViewChat and CreateInteraction do (no "SHOULD return context as a result" and no output section). finos-mcp reports no result for them, because the specification text states none; a consumer cannot tell whether fdc3.chat.room is guaranteed. Pinned by a test. Reported as finos/FDC3#2270.