Follow a loan balance to its filing

What does WFCM 2020-C58 report for asset 25, and which filing supplied the observation?

See the same loan in Cairn's worked example for the short answer and the questions it raises. This guide shows the individual calls and source limits.

On November 4, 2026, we ran this question through EDGAR, Reveal, Data and Evidence. The October observation reported $9,268,821.88 scheduled and $9,399,496.50 actual. Keeping those field names matters: the numbers describe different balances for the same loan record.

You need arranged access to all four MCP services and the relevant warehouse tables. Contact us for access. The calls below use public filing-derived data. Table selection and the handoffs between calls are explicit steps you or your agent perform.

1. Resolve the deal and find its filings

Call EDGAR's edgar.com.entity.resolve with:

{"query":"WFCM 2020-C58","limit":3}

The response returned decision: resolved, entity reference cmdrvl:DEAL-WFCM-2020-C58 and CIK 1827054. Its deals registry was dated September 28, 2026. Stop for clarification if resolution is ambiguous; a similar deal name is not a safe join.

Pass the returned entity reference to edgar.com.entity.filings:

{"entity_ref":"cmdrvl:DEAL-WFCM-2020-C58","form_type":"ABS-EE","since":"2026-09-01","limit":10}

The index returned two ABS-EE filings without truncation:

These links come from the extracted EDGAR index. This call constructs SEC URLs; it does not fetch and inspect the archive documents. A gap in the index would not establish that a filing is missing from the SEC archive.

2. Choose a table that fits the question

Pass the same entity reference to Reveal's cmdrvl.com.entity.data:

{"entity_ref":"cmdrvl:DEAL-WFCM-2020-C58","schema":"PROPERTY_MART","limit":25,"offset":0}

The first page returned 25 of 42 catalog matches, including snowflake://edgar_db.property_mart/loan_period_fact. Its CIK column was tagged with the entity key. We selected this table because its description specifies one loan observation per CIK, asset number and reporting period. The catalog tag identifies a possible join; the query below establishes that matching rows exist.

Call cmdrvl.com.metadata.lookup with the returned key:

{"reference":"snowflake://edgar_db.property_mart/loan_period_fact","limit":3}

That resolved the physical table to EDGAR_DB.PROPERTY_MART.LOAN_PERIOD_FACT. This is a catalog lookup and a deliberate table choice, not automatic interpretation of every filing.

3. Read the fields before asking for values

In Data MCP, call edgar_data.list_tables with schema: PROPERTY_MART, limit: 200 and offset: 0. The response included the table, but returned only 47 of 56 tables because of its response budget. Then call edgar_data.describe_table with table: PROPERTY_MART.LOAN_PERIOD_FACT.

The description returned 136 columns. It defines scheduled balance as the scheduled or stated period-end principal, and actual balance as the outstanding balance at the reporting-period determination date. Neither field by itself establishes an entire whole-loan exposure across other notes or deals. Asset number alone also repeats across deals, so preserve the CIK.

Call edgar_data.run_query with limit: 10 and this SQL:

SELECT CIK, ASSETNUMBER, REPORTINGPERIODENDDATE,
       FILING_DATE, FILING_ID,
       REPORTPERIODENDSCHEDULEDLOANBALANCEAMOUNT,
       REPORTPERIODENDACTUALBALANCEAMOUNT
FROM EDGAR_DB.PROPERTY_MART.LOAN_PERIOD_FACT
WHERE CIK = '1827054' AND ASSETNUMBER = '25'
  AND FILING_ID IN ('0001888524-26-019266', '0001888524-26-017937')
ORDER BY REPORTINGPERIODENDDATE DESC NULLS LAST,
         FILING_DATE DESC NULLS LAST
LIMIT 10

The result contained two rows with complete: true for this query:

Each row's FILING_ID exactly matched the corresponding ABS-EE accession from step 1. That is a stronger connection than sharing a CIK. A 10-D accession for the same issuer would identify a different document.

The reporting-period date tells you when the balance applies. The filing date tells you when it was disclosed. Preserve both, along with the accession, field name, query and response. Do not replace a null balance with zero or silently substitute the other balance field.

4. Inspect the recorded upstream dependencies

Pass the same catalog key to Evidence's evidence.trace_lineage:

{"entity_key":"snowflake://edgar_db.property_mart/loan_period_fact","direction":"upstream","depth":6}

The November 4 response returned 28 nodes. Sixteen had no source-code pointer, and column_lineage_available: false. The graph includes dependencies for the broader table, including rate data; it is not a filing-specific trail for this balance. We retained the response, but did not treat it as verification of either balance or publish private source pointers.

At this point we have a named entity, a described field, two dated observations and matching filing identifiers. We also know where the evidence stops. To inspect a particular calculation, you would need the producing code and a value-level check. This run did not supply that check.

The same question through Cairn's lookup backend

We also ran a fresh question through the Loom backend used by Text Cairn on November 4. We asked for asset 25's scheduled and actual balances for October 13, the filing identity and date, and the limits of the source evidence. This exercised the lookup backend directly, without sending a text message or testing customer memory.

The demonstration prompt supplied the CIK, asset and period, restricted the run to four named read-only tool families, set a one-row query limit and lineage depth of 3, and requested the caveats. It tests that constrained lookup, not unrestricted tool selection.

The recorded run made six read-only tool calls:

1. Three metadata lookups searched the prefixes abs_ee, loan and asset. Only loan returned matches, including the loan-period table.
2. data_describe_table read the table's columns and definitions.
3. data_run_query selected the exact CIK, asset and reporting period, returning one complete row.
4. evidence_trace_lineage inspected the table at depth 3.

The answer returned the same October balances and ABS-EE accession shown above. Its lineage request returned 26 nodes, with 14 missing source pointers and no column-level lineage. This run did not call EDGAR's filing-index tool, export CSVs or seal a package. Those are separate steps demonstrated in these guides.

The model also suggested possible reasons for a scheduled-versus-actual difference. The returned row did not establish any of those causes, so they are not part of the supported answer here. The useful result is the dated, field-specific observation and an explicit account of what remains unchecked.

This is one observed route from a constrained question to an answer. The suite diagram does not imply that every request runs through every tool.

Keep the answer with its evidence

For a reviewable answer, retain the resolution and registry version, filing-index result, table description, SQL, returned rows and lineage response. Compare these two periods and seal the files to preserve the inputs and comparison output together. Package verification checks that those bytes have not changed; it does not establish that a filing is correct.

If access fails, request the missing service or table scope. If resolution is ambiguous, a filing identifier does not match, or the query is incomplete, stop and resolve that gap before presenting the number as a sourced answer.

See how these contributions fit how Cairn works and what supports an answer. For individual connection steps, use the tool guides.