Integration Surface

Technical-Documentation • — • 3 min read

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

Executive Summary

FMAE does not have a public, external REST API as of this writing. What it does have is a deliberately narrow internal Python integration contract — a single module that re-exports only the specific names another internal package genuinely needs, growing one name at a time only when a concrete use case requires it. This page states plainly that no external API exists today, and documents the shape of the internal contract that does, since "does this tool have an API" is a common and legitimate integration question that deserves an honest answer either way.

Key Takeaways

✓ FMAE has no public, external REST API today — this page states that plainly rather than leaving the question unanswered or implying one exists.
✓ What does exist is a narrow internal Python integration contract, currently consumed by exactly one internal package, re-exporting only specific names that package genuinely needs.
✓ The contract grows one name at a time, only when a concrete use case requires it — it is not pre-populated with names "for later."
✓ Internal package names and internal implementation detail are deliberately not disclosed on this page; what is documented is the shape and discipline of the contract itself.

What This Page Documents¶

This page answers, honestly, a common integration-evaluation question: does FMAE have an API. As of this writing, it does not have a public, external API. It does have a real, narrow internal integration contract, and this page documents that contract's shape and design discipline — without implying it is, or is becoming, a public API, and without naming the specific internal package that currently consumes it.

No External API Today¶

There is no external REST API, and no other network-facing integration surface, exposed by FMAE as of this writing. A reader evaluating FMAE for integration into another system should take this as a direct, current answer, not as an omission.

The Internal Integration Contract¶

What does exist is a single internal Python module functioning as the only supported integration surface for code outside the audit engine's own package. Its design follows a small number of explicit rules:

Re-exports only, never logic. The contract module contains no computation of its own — it only names which existing objects and functions, defined elsewhere in the engine, are safe for outside code to depend on.
Grows one name at a time, on demand. A name is added to the contract only when a concrete, current use case in a dependent package genuinely needs it — never pre-emptively, "for later."
Everything else is an internal implementation detail. Any part of the engine not explicitly re-exported through this contract may change at any time without notice. Consumers outside the engine's own package are expected to import only from this contract module, never from the engine's internal modules directly.

What the Contract Currently Exposes¶

As of this writing, the contract exposes, at a conceptual level: the workbook-parsing entry point (turning an .xlsx file into a structured manifest); the findings, evidence, and narrative data model; a small set of shared row-pattern-comparison helpers; the formula-grammar query surface used to inspect a formula's structure without regex; the engine's narrow rule-pack execution interface (register and execute a rule pack by identity, never the internal engine or registry classes directly); the SM-2.0 scoring computation entry point; and the canonical RT-3.1 report-generation entry points (see Report Generation) — deliberately excluding the retired RT-3 report engine's equivalents, since a new consumer has no reason to reach a component being phased out.

Why This Design, Stated Honestly¶

A narrow, explicitly curated integration surface means the engine's internal structure — how parsing, graph construction, rule execution, and scoring are implemented internally — can evolve without breaking anything built against the contract, as long as the contract's own names and behavior stay stable. This is a genuine architectural property of the current codebase, not a hypothetical design goal: it is already load-bearing for the one internal package that consumes it today, and is the same discipline this Technical Documentation library itself follows in describing internal mechanism conceptually rather than disclosing implementation detail that could change without notice.

Rule Engine & Rule Packs — the narrow rule-pack execution interface this contract re-exports.
Report Generation — why the contract exposes RT-3.1's entry points and deliberately not RT-3's.
FMAE Audit Engine — Architecture Overview — the full pipeline this contract provides external access into.

How OXXON tests thisRun a free structural check with FMAE

Frequently Asked Questions

Does FMAE have a public API?

Not as of this writing. There is no external REST API. What exists is a narrow internal Python integration contract, used today by one internal consumer, and this page documents that honestly rather than implying a public API exists.

What does the internal integration contract expose?

A curated set of re-exports only — the workbook-parsing entry point, the findings and evidence data model, the rule engine's narrow public execution interface, the SM-2.0 scoring entry point, and the canonical RT-3.1 report-generation entry points — never the engine's internal machinery directly.

Why is the contract described as narrow by design?

Because everything not explicitly re-exported through it is treated as an internal implementation detail that may change without notice. Consumers outside the engine's own package are required to import only through this contract, which is what allows the engine's internal structure to evolve without breaking anything built on top of it.

Will FMAE add a public API in the future?

This page describes the engine's real, internal integration surface as it exists today. It does not speculate about or commit to a future public API, consistent with this documentation's standing rule against describing functionality that does not yet exist.

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.

Rule Engine & Rule Packs

FMAE's 26 structural rules are not called individually. They are registered into a single named, versioned rule pack — fmae.structural, version 1.0.0 — and executed as a unit through a narrow public interface (register_rule_pack / execute_rule_pack), never through direct access to individual rule classes from outside the engine. Every finding the pack produces is stamped with exactly which engine version and rule pack version produced it, so a finding from any past audit remains attributable to the exact rule logic that generated it.

Report Generation

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.