DealCharts case study: explainable CMBS data

Most capital markets teams already have models. The harder problem is keeping the source context attached after a model run, chart, or portfolio update moves into a decision.

DealCharts started with structured finance because CMBS has clear identifiers, recurring disclosure material, and enough source variation to expose the problem quickly. A single view can depend on SEC filings, servicer reports, trustee statements, rating-agency commentary, computed metrics, and analyst review.

Short answer: DealCharts shows how structured-finance data can become explainable infrastructure. Each material fact carries a stable ID, source link, as-of date, update timestamp, and method note, so the number can be inspected after it appears in a chart, model, or downstream workflow.

The problem: data without context

Structured finance data is rarely missing because nobody knows where to look. It is fragile because the source context gets separated from the number.

Across credit, rates, equities, alternatives, and private data rooms, the same pattern repeats:

1. Fragmented sources: filings, reports, APIs, vendor feeds, and internal marks live in separate systems.
2. Disposable model runs: assumptions and outputs are saved as files, not durable records.
3. Weak provenance: source references are manual, partial, or absent.
4. Unreviewable outcomes: a chart or scenario can outlive the evidence that produced it.

The result is slow reconstruction. When a PM, risk lead, investor-relations team, or compliance reviewer asks where a number came from, analysts have to rebuild the path from reports, emails, exports, and memory.

The DealCharts pattern

DealCharts uses a simple operating principle:

Every dataset, fact, and model output should carry the context required to inspect it later.

For CMBS, that means connecting deal identifiers, filing records, report dates, normalized fields, computed metrics, and chart outputs in one inspectable graph. The result is a record that can answer:

• Which source produced this fact?
• What date did it describe?
• When did we ingest or update it?
• What method normalized or calculated it?
• What did this value replace?
• What limits or review notes apply?

That pattern is the Context-Through-Provenance Model in practice. Data is not treated as a flat table. It is treated as a set of connected facts with source memory.

Architecture: from tables to context

The implementation revolves around three ideas: stable identifiers, machine-readable facts, and provenance fields.

Stable identifiers

dcid:deal/<shelf><year>-<series>
dcid:fund/<lei>
dcid:portfolio/<uuid>

Each material entity gets a deterministic ID. In structured finance, that can mean deals, bonds, issuers, funds, portfolios, documents, and computed views. Identifiers make joins reviewable because the relationship does not depend on a spreadsheet tab name or an analyst's local convention.

Machine-readable facts

Every page, dataset, or model output can expose a structured representation, such as /facts/<slug>.json, with the fields a person or agent needs to inspect the result:

• inputs and assumptions,
• outputs and metrics,
• timestamps and sources,
• version hashes or prior-state references,
• review status and known limits.

Provenance as a field

Every important record carries a source path:

{
  "isBasedOn": ["source_url_1", "source_url_2"],
  "updated_at": "2025-10-03T12:00:00Z",
  "curated_by": "system|analyst",
  "confidence": 0.98
}

That turns a number into an inspectable object. The record does not ask the reviewer to trust a chart by itself. It keeps the source, timing, and method next to the value.

Practical impact for data teams

For a capital markets data team, this changes the operating model. Instead of rebuilding one-off pipelines for each model or strategy, teams can run analytics against records that preserve:

• What changed: source-level diffing and prior-state comparison
• When it changed: as-of dates, ingest time, and update time
• Why it changed: source references, methods, and review notes
• Who reviewed it: curator or system attribution where appropriate

That enables faster model reruns, cleaner backtests, more reliable review logs, and safer agent workflows. The gain is not that analysts stop using judgment. The gain is that analysts spend less time proving what the input state was.

From CMBS to adjacent domains

CMBS was the starting point because the domain has clear identifiers, structured filings, and observable updates. The same graph pattern can apply wherever the team needs durable state across related entities.

Domain	Example entity graph
Credit and loans	loan, borrower, collateral, servicer
Equities	issuer, filings, corporate actions, index memberships
Rates and macro	curve, data source, policy event, derived metric
Alternative data	dataset, provider, transformation, output variable
Fund data	position, security, source feed, model version

The domain changes. The requirement stays the same: facts need identifiers, source references, time, and method.

Transparency without public disclosure

Private teams do not need to publish proprietary positions to benefit from this model. Transparency can be internal. It means the team can inspect the evidence behind its own outputs.

The DealCharts playbook translates cleanly into internal infrastructure:

• expose important datasets as verifiable objects,
• keep source and method fields with the record,
• version model outputs automatically,
• tie each material variable back to source material,
• preserve review notes beside the result.

This reduces reconciliation risk and makes investor, risk, and compliance conversations less dependent on ad hoc reconstruction.

Time as metadata

Markets move, but warehouses often flatten time. DealCharts treats temporal fields as part of the record, including valid_from, valid_to, updated_at, and the source as-of date.

For funds and research teams, this makes it easier to:

• Recreate the exact state of data as of any date,
• Detect drift between versions,
• Audit signals used in historical backtests, and
• Align research timelines with data reality.

Time stops being a hidden assumption. It becomes part of the evidence.

From datasets to agents

Agent workflows need more than access to a table. They need enough context to avoid confusing stale state, derived values, and unreviewed facts.

In the DealCharts pattern, every entity carries:

• a stable ID,
• machine-readable context,
• source references,
• timing fields,
• method notes,
• review status.

That gives LLMs, research assistants, and automation a safer substrate. They can query, compare, and summarize records without losing the evidence path a human reviewer will need later.

Operational advantages

For hedge funds, asset managers, and structured-finance teams, the payoff is practical:

• Faster model iteration: rerun or backtest from stored context.
• Explainable outputs: inspect the source path behind a chart or scenario.
• Cross-domain joins: link credit, macro, and alternative data through stable IDs.
• Lower reconciliation load: reduce manual source gathering and state checks.
• Review readiness: keep source, method, and limits with the result.

When every important number keeps its source path, models become easier to test and easier to defend.

What the pattern requires

The buildout is straightforward but discipline-heavy:

1. Identify the entities that matter.
2. Expose facts in structured form.
3. Attach source links, timestamps, methods, and limits.
4. Version state so prior values remain inspectable.
5. Review exceptions before downstream systems treat the record as decision-ready.

Replace CMBS with portfolio, loan, issuer, curve, fund, or macro dataset, and the same operating model still holds.

The pattern is simple: run, store, contextualize, publish, explain.

Common questions

What did DealCharts show for structured finance data?

DealCharts showed that CMBS data can be published with stable identifiers, source links, timestamps, and method notes so analysts can inspect where a number came from after it appears in a model output or chart.

Why does CMBS data need a context graph?

CMBS data crosses filings, trustee reports, servicer material, rating-agency commentary, and computed metrics. A context graph keeps those entities and source relationships connected instead of leaving them scattered across tables and files.

What should explainable financial data preserve?

Explainable financial data should preserve the source document, as-of date, ingest time, calculation method, prior state, known limits, and review status for each important fact.

How does the DealCharts pattern apply outside CMBS?

The same pattern applies anywhere teams need durable state across instruments, issuers, positions, borrowers, portfolios, or market context. The domain changes, but the need for IDs, source references, versioning, and review notes remains.

Last updated July 6, 2026. Sources: DealCharts GEO Playbook and CMD+RVL Signals.

---

Related

Structured finance deep dive:

• CMBS deal tracking with evidence - evidence-backed monitoring for structured portfolios

Apply this to your portfolio:

• CMBS Ownership Monitor for N-PORT Holdings - track who owns CMBS securities based on public fund disclosures
• Prospectus Market Context Snapshot - capture rates, curves, and calendars at analysis time
• Borrower Disclosure Monitor - track disclosure changes for CLO borrowers

How it works:

• Evidence Packs - how we make outcomes defensible
• Book discovery - turn signals into a qualified outcome path