Report Generation

Technical-Documentation • — • 3 min read

Audience: Technical Reviewers • Auditors • Integration Engineers
Last Reviewed: July 2026
Updated: Version 1.0

Executive Summary

Report Generation is the final stage of the FMAE audit pipeline, composing the outputs of every earlier stage — the score, the findings, their evidence, and the engine's provenance — into a structured report document. Two generations of report engine exist in the codebase today, one retired and one canonical. RT-3, the original report engine, is being retired; RT-3.1 is the current, canonical reporting engine, producing two on-demand report models rather than one monolithic document — an Executive Decision Report and a separate supporting Annex.

Key Takeaways

✓ Report Generation is the final pipeline stage, composing the score, findings, evidence, and provenance every earlier stage produced into a structured report document.
✓ Two report-engine generations exist in the current codebase — RT-3, being retired, and RT-3.1, the current, canonical reporting engine.
✓ RT-3.1 produces two separate report models on demand rather than one monolithic document — an Executive Decision Report, always generated, and a supporting Annex, generated separately only when requested.
✓ A dedicated Trust section, populated entirely from a governed, fixed text registry plus the audit's own provenance fields, appears in the report specifically to state the audit's own verifiable identity — engine version, source file hash, control count — rather than persuasive language.

What This Stage Does¶

Report Generation is the fifth and final stage of the FMAE audit pipeline: it composes the score, the findings, their supporting evidence, and the engine's provenance — the outputs of every earlier stage — into a structured report. This page documents what a report contains as a structured object and the engine's own history on this specific stage, honestly, including a report-engine generation that is currently being retired.

Two Report-Engine Generations¶

Two distinct report engines exist in the codebase as of this writing:

RT-3 — FMAE's original report engine, currently being retired. Its equivalents are deliberately not exposed through FMAE's internal integration surface (see Integration Surface), since new consumers of the engine have no reason to reach a component being phased out.
RT-3.1 — the current, canonical reporting engine. It is the only report engine whose entry points are exported through the integration surface, and the one actively used to produce audit reports today.

This page describes both honestly: RT-3's structure as historical context for how the report layer has evolved, and RT-3.1's structure as the current, operative mechanism.

RT-3.1: Two Report Models, Not One Document¶

Where RT-3 assembled a single combined report document, RT-3.1 produces two separate report models through two distinct entry points:

The Executive Decision Report (EDR) — generated for every audit, carrying the report's executive-facing content: a cover, a trust statement, an executive story and decision framing, executive priorities, a findings summary, an action register, and a coverage summary.
The Annex — a separate, more detailed supporting document, generated only on demand rather than for every audit, carrying the fuller supporting detail: a controls catalogue, detailed coverage information, full evidence, provenance detail, and reliance statements.

Separating these into two models rather than one document reflects that an executive reader and a technical reviewer verifying a specific finding have different needs — the EDR is built to be read in full by a decision-maker, while the Annex exists specifically for the reader who needs to trace a finding back to its full supporting detail.

The Trust Section¶

Both RT-3 and RT-3.1 carry a dedicated Trust section, populated entirely from a fixed, governed text registry plus a small set of merged fields drawn directly from the audit's own provenance: the engine version, a cryptographic hash of the source file, the report template version, and the number of controls applied. By design, nothing else is permitted to appear in this section — it exists specifically to state the report's own verifiable identity in fixed, non-variable language, rather than to persuade. This is a deliberate, narrow design choice: a section whose content is drawn only from governed text and objective provenance fields cannot drift into marketing language over time, by construction.

Evidence & Provenance — the provenance and evidence model a report's content is assembled from.
FMAE Scoring Engine — SM-2.0 Methodology — the score a report presents.
Integration Surface — why RT-3's equivalents are not exported alongside RT-3.1's.
FMAE Audit Engine — Architecture Overview — where this stage sits in the overall pipeline.

How OXXON tests thisRun a free structural check with FMAE

Frequently Asked Questions

What does an FMAE audit report actually contain, as a structured object?

A composition of the audit's score, its findings (each with evidence and a narrative), the engine's provenance (version, source file hash, rule pack versions), and a coverage disclosure — assembled by the Report Generation stage into a structured report model before being rendered to a document format.

What is the difference between RT-3 and RT-3.1?

RT-3 is FMAE's original report engine and is being retired. RT-3.1 is the current, canonical reporting engine — the one actively used and the only one whose equivalents are exported through FMAE's internal integration surface.

Does FMAE produce one report document or more than one?

Under the current, canonical RT-3.1 engine, two separate report models are produced — an Executive Decision Report, generated for every audit, and a separate supporting Annex, generated only when specifically requested, rather than a single combined document.

What is the Trust section?

A report section populated entirely from a fixed, governed text registry plus the audit's own verifiable provenance fields (engine version, a cryptographic hash of the source file, and the number of controls applied) — nothing else is permitted to appear in it, by design, so it functions as a stable, checkable statement of the report's own origin rather than persuasive or variable language.

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.

FMAE Scoring Engine — SM-2.0 Methodology

FMAE computes a model's risk score as 100 minus the triggered rules' combined weight, normalized against a fixed basis, currently 207.0 under the active SM-2.0 methodology. SM-1.0, the engine's original scoring basis (170.0, covering R001–R021), is retained as a frozen historical reference rather than deleted from the record. Five rules — R001, R002, R004, R006, and R023 — are critical-override rules. If any of them triggers, the resulting letter grade is capped so a model cannot be graded A or B regardless of how high its numeric score is. This page documents the exact formula, the versioning between SM-1.0 and SM-2.0, and a fully worked example.