Rule Engine & Rule Packs
Executive Summary
Key Takeaways
- ✓ FMAE's rules are registered into a single named, versioned rule pack (fmae.structural, version 1.0.0) and executed as a unit, not called individually from outside the engine.
- ✓ A rule pack executes completely or not at all — if a pack's declared manifest schema version does not match the manifest it is given, zero rules run and zero findings are emitted, never a partial result.
- ✓ Every finding is stamped with the exact engine version and rule pack version that produced it, so a finding from a past audit remains attributable to the exact rule logic that generated it.
- ✓ The engine's architecture already generalizes beyond one rule pack, but fmae.structural is the only published, public rule pack as of this writing — this page does not describe or imply any other.
What This Stage Does¶
Rule Engine & Rule Packs is the third stage of the FMAE audit pipeline: it executes the engine's structural rules against the dependency graph the previous stage built, and produces the findings that scoring and reporting consume. This page documents the execution model — how 26 individual rules become one coherent audit run — not the list of rules themselves, which is documented on the Rule Taxonomy and Rule Reference pages.
Rules Are Registered Into a Rule Pack, Not Called Individually¶
FMAE's 26 structural rules are registered into a single named, versioned collection — a rule pack —
identified as fmae.structural, version 1.0.0. The engine executes rule packs by identity through a
narrow public interface (register_rule_pack and execute_rule_pack), rather than through direct access
to individual rule classes from outside the engine. Internally, every rule in the pack declares its own
category, severity, weight, and other static attributes at the point it is defined; the pack is simply the
named, versioned collection those rule definitions are registered into.
Execution Is All-or-Nothing¶
Before running any rule, the engine checks that the rule pack's declared manifest schema version matches the actual manifest it has been given. If the two do not match, the engine executes zero rules and emits zero findings — a rule pack runs completely, against a manifest shape it was built for, or it does not run at all. This avoids a subtler failure mode: a rule pack partially executing against a manifest shape it was not designed for, and producing findings that look complete but are silently missing checks the pack was supposed to run.
Provenance Is Stamped by the Engine, Not by Individual Rules¶
Every finding a rule produces is stamped, by the engine itself rather than by the individual rule, with the exact engine version and rule pack version (identity and version number) that produced it. This matters for reproducibility: a finding from an audit run at any point in the past remains attributable to the exact rule logic that generated it, independent of whatever the current, possibly-updated rule code believes about itself today. The engine also records, once per rule pack per manifest, that this exact pack version was executed against this exact manifest — re-running the same pack version is a no-op on that record, but recording two different versions of the same pack against the same manifest is treated as an error rather than silently overwritten, since a manifest carrying two disagreeing statements about which rule pack version audited it would undermine the reproducibility the provenance record exists to guarantee.
One Rule Pack Today, an Architecture That Generalizes¶
The engine's execution interface does not assume fmae.structural is the only rule pack that will ever
exist — the same register_rule_pack / execute_rule_pack interface is built to support more than one.
As of this writing, however, fmae.structural is the only published, public rule pack. This page
describes that architecture honestly without implying or describing any other rule pack, because none is
public today.
Related Reading¶
- FMAE Rule Taxonomy — the classification of the 26 rules this pack executes.
- Rule Reference — individual pages for each rule in the pack.
- FMAE Scoring Engine — SM-2.0 Methodology — how the findings this stage produces are scored.
- FMAE Audit Engine — Architecture Overview — where rule execution sits in the overall pipeline.
How OXXON tests thisRun a free structural check with FMAE
Frequently Asked Questions
How does FMAE decide which rules to run?
Rules are not selected individually. They are pre-registered into a single named, versioned rule pack (fmae.structural), and the engine executes that pack as a whole against a given workbook's manifest.
What happens if the rule pack and the manifest don't match?
The engine checks the rule pack's declared manifest schema version against the manifest's actual schema version before running anything. If they don't match, zero rules execute and zero findings are emitted — a rule pack runs completely or not at all, never partially.
Can a finding be traced back to the exact rule logic that produced it?
Yes. Every finding is stamped with the engine version and the rule pack version (identity and version number) that produced it, independent of what any individual rule class believes about itself — so a finding from an audit run months or years ago remains attributable to the exact logic that was live at the time.
Does FMAE support more than one rule pack?
The engine's execution interface is built to support more than one rule pack, but fmae.structural is the only rule pack that is published and public today. This page does not describe or imply the existence of any other rule pack.
Related Articles
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.
FMAE Rule Taxonomy
Every rule in the FMAE structural rule pack declares a category attribute at the point it is defined in source — this is not a classification imposed on the rules afterward for documentation purposes, it is the classification the engine itself uses. Six categories cover all 26 rules — Structural (18 rules), Assumptions Governance (1), Integrity Controls (2), Structural Hygiene (1), Aggregation Logic (1), and Model Governance (3). This page publishes that taxonomy as the FMAE equivalent of a control catalog's classification scheme, cross-linked to the Rule Reference page for each member rule.
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.