Coverage & Disclosure

Technical-Documentation • — • 3 min read

Audience: Technical Reviewers • Auditors • Lenders • Investment Committees
Last Reviewed: July 2026
Updated: Version 1.0

Executive Summary

Every FMAE audit carries a coverage disclosure — a machine-readable statement of what kinds of references the engine's reference resolver did and did not resolve into graph edges for that parse. Rather than silently assuming full coverage of a workbook's reference graph, FMAE states plainly what it resolved (single-cell references) and what, in this version of the platform, it does not (structured table references, most dynamic references), and counts how many instances of each were present. This is a transparency mechanism, not a marketing claim, and is a genuine limitation stated honestly rather than omitted.

Key Takeaways

✓ FMAE discloses, per audit, exactly what kinds of workbook references its reference resolver did and did not resolve into the dependency graph — rather than silently assuming complete coverage.
✓ Single-cell references are fully resolved in the current platform version; defined names, structured table references, external references, and dynamic references have disclosed, version-specific resolution behavior, each with its own instance count.
✓ The disclosure is machine-readable, not just descriptive prose, and is designed to automatically reflect any future addition to what the platform can resolve, rather than needing a manual rewrite.
✓ A coverage limitation being disclosed does not mean the audit is incomplete in an undisclosed way — it means the platform states plainly what a reader should know before treating the audit's coverage as total.

What Coverage Disclosure Is¶

Every FMAE audit carries a coverage disclosure — a machine-readable statement of what proportion, and what categories, of a workbook's reference graph the engine's reference resolver was able to resolve into the dependency graph for that parse. Rather than silently assuming complete coverage of every kind of reference a workbook might contain, FMAE states plainly what the current platform version resolves and what it does not.

This is a transparency mechanism, not a marketing claim. It exists specifically so a reader can judge an audit's actual scope rather than assume, without being told, that every reference in the workbook was necessarily reachable by the engine's analysis.

What Is Disclosed¶

The disclosure covers six categories of reference, stated for the current platform version, each paired with a count of how many instances of that reference type were actually found in the workbook being audited:

Reference category	Current platform version
Single-cell references	Resolved
Range references	Counted, not expanded into individual cell-level edges
Defined names	Not resolved
Structured table references	Not resolved
External workbook references	Not traversed
Dynamic references (such as those built with `INDIRECT` or `OFFSET`)	Not resolvable
Unparsed formulas	Counted

A true/false resolution state and an instance count are disclosed for each category on every audit, not just the categories where the workbook actually has a gap — so a workbook with zero defined names still states plainly that defined-name resolution is not yet performed, rather than the disclosure being silent simply because this particular workbook did not exercise the limitation.

Why the Disclosure Is Machine-Readable, Not Just Prose¶

The disclosure is built directly from the coverage record's own declared fields, so it is generated rather than separately hand-written for each report. This means the disclosure automatically reflects any future change to what the platform resolves — if a future version adds resolution for a category not resolved today, the disclosure updates to reflect that without requiring a parallel rewrite of report-generation logic.

A Limitation Stated Honestly Is Not an Incomplete Audit¶

A disclosed coverage gap does not mean the audit silently missed something it should have caught. It means the platform states, in specific and checkable terms, the boundary of what a given version's reference resolution actually reaches — for example, that most dynamic references built with functions such as INDIRECT are not resolved in the current version, and how many such references the workbook being audited actually contains. A reader relying on the audit's findings can weigh that disclosed boundary directly, rather than discovering it only if something goes wrong later.

Evidence & Provenance — the coverage disclosure is carried inside every evidence bundle alongside the audit's provenance.
Dependency Graph & Circularity Detection — the dependency graph this disclosure states the resolution coverage of.
Parsing & Workbook Ingestion — the stage that produces the reference facts this disclosure reports on.

How OXXON tests thisRun a free structural check with FMAE

Frequently Asked Questions

Does an automated audit tool disclose what it could and couldn't analyze?

FMAE does, through a dedicated coverage disclosure attached to every audit — a machine-readable statement of which categories of workbook reference were resolved into the dependency graph and which were not, for that specific platform version.

What does FMAE's coverage disclosure actually cover?

Six categories — single-cell references, range references, defined names, structured table references, external workbook references, and dynamic references — each stated as resolved or not resolved for the current platform version, with an instance count for each category found in the workbook.

Is a coverage limitation the same as a defect?

No. A stated coverage limitation is a disclosed boundary of what a given platform version resolves into its dependency graph — for example, most dynamic references are not resolved in the current version. Disclosing this is the opposite of a defect — it is what lets a reader judge the audit's scope accurately rather than assuming complete coverage that was never claimed.

Why does this disclosure matter to a lender or investment committee?

Because it answers, in specific and checkable terms, a question that matters to anyone relying on an audit's findings — what did the audit actually look at, and what, if anything, did it not reach.

FMAE Audit Engine — Architecture Overview

The FMAE audit engine processes a workbook through five stages executed in a fixed order — parsing and workbook ingestion, dependency graph construction, rule engine execution, risk scoring, and report generation. Each stage consumes the previous stage's output and exposes nothing about how any later stage will use it, so the stages can be documented, tested, and read about independently. This page is the map; the detail behind each stage lives on its own Technical Documentation page as those pages are published.

Evidence & Provenance

FMAE separates two concerns that are easy to blur together — evidence (the specific facts that justify a finding) and provenance (the record of what engine, rule pack, and source file produced it). An evidence bundle is a deterministic export of facts the platform has already computed elsewhere — the manifest's own provenance and coverage disclosure, an explicit set of findings, and any circular dependency regions those findings touch — copied verbatim, never recomputed or inferred at export time.

Dependency Graph & Circularity Detection

FMAE builds a directed graph linking every formula cell to the cells its formula references, then applies strongly-connected-component (SCC) analysis — a well-established computer-science technique for finding groups of nodes that are mutually reachable from one another — to identify every circular calculation in the workbook, however large or deeply nested. Each detected circular group is condensed into a single node in a further graph (the condensation graph), which is guaranteed acyclic and supports reachability analysis used elsewhere in the engine, such as measuring how far a finding's impact could propagate downstream.