Pillar · Cross-module intelligence
The patterns one number can't show.
79 pattern rules across 11 families. Deterministic. Sample- size-aware. Surfaced as diagnostic findings, never as verdicts. The Claude Opus narrative layer runs under a four-layer hallucination guard.
Strategy without shipping
Declared AI strategic posture at 4.1/5; AI velocity at 2.4/5. The board sees ambition; capability falls behind.
Governance lagging operationalisation
Production readiness at 3.7/5; AI ethics operationalisation at 2.9/5. Models in production outpace the review board.
Value without instrumentation
Customer-facing AI at 3.6/5; value realisation at 2.9/5. Pilots running; dollar-impact attribution still soft.
Agent autonomy without oversight
Agentic AI maturity rising faster than human-AI collaboration. Autonomy outpacing the human review surface.
Why a rule engine, not a pure-LLM pipeline
Determinism on the load-bearing layer. The rule that fires “strategy without shipping” is a pure function, same inputs, same output, every time. No LLM creativity at the diagnostic boundary.
Sample-size awareness. Rules in Family K suppress firings on thin evidence. A pattern that needs ≥6 contributing modules to support an inference never fires on 3.
Hallucination guard on the narrative layer. When Claude Opus narrates a finding, it sees only the structured rule output. The allow-list rejects any module ID the LLM names that isn't in the input. Fallback to deterministic prose when validation fails.
Frequently asked
What is cross-module intelligence?
The Transformics rule engine evaluates 79 pure-function pattern rules across 11 families (A–K) against the live module scores. Each rule encodes a pattern that a single module's number can't surface, strategy without shipping, governance lagging operationalisation, agent autonomy without oversight, value realisation without instrumentation, and so on. The output is a ranked list of diagnostic findings, not a list of verdicts.
How is a finding generated?
Each rule is a pure Python function that takes the current module-score map and returns either nothing (rule didn't fire) or a structured finding: rule_id, title, finding, implication, actions, severity, category, affected_modules, matched_scores, confidence, and a sample-size warning where appropriate. The rule engine itself is deterministic; only the narrative synthesis on top is LLM-generated.
Examples of rules?
Family A, strategy / execution gap (e.g. high AI strategic posture but low AI velocity). Family B, governance lag (production readiness ahead of ethics operationalisation). Family C, value realisation gap (customer-facing AI shipping without dollar-impact instrumentation). Family K, sample-size + comparability-aware rules that suppress otherwise-firing patterns when the underlying evidence is too thin to support the inference.
What stops the rule engine from over-firing?
Three guards: (1) every rule is sample-size-aware, Family K rules suppress firings on thin evidence; (2) every finding ships with a confidence score and a sample-size warning when appropriate; (3) the cockpit Insights surface ranks findings by severity and surfaces the rule's matched_scores so a reader can see exactly which numbers triggered the pattern.
How does the LLM narrative layer fit in?
Claude Opus synthesises the rule-engine output into board-room prose under a four-layer hallucination guard: system-prompt isolation (the LLM only sees the structured rule output, not raw data), enforced JSON schema, snake_case allow-list validation against the input module IDs, and a deterministic templated fallback when any layer rejects the LLM output. Every narrative ships with an ✨ AI-generated badge.
See the rule engine in action on the demo cockpit.
Open demo cockpit →