Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/acdeveloper-sci/fortriage/llms.txt

Use this file to discover all available pages before exploring further.

Every Fortran unit analyzed by ForTriage is assigned a risk tier based on a numeric Score computed by Forti4D. The tier determines display color, sort order, and priority in AI Insights recommendations. Understanding how tiers map to modernization actions is essential for interpreting the Overview dashboard, the Drill-down view, and the AI-generated summaries.

​
The Five Tiers

ForTriage surfaces five tiers in canonical priority order. Each tier carries a distinct color used consistently across summary cards, bar charts, table badges, and the Drill-down modal.
TierColorHexMeaningRecommended Action
CRITICAL🔴 Red#D64545Highest composite risk score. Likely a core knot (high CC × high Fan-In) or a unit with severe legacy constructs.Immediate attention required — address before any modernization sprint begins.
HIGH🟠 Orange#E8874ASignificant risk — high complexity, high coupling, or extensive legacy constructs.Address in the next modernization sprint.
MEDIUM🟡 Yellow#E8C547Moderate risk — notable issues but not blocking other work.Schedule for refactoring; deprioritize relative to CRITICAL and HIGH.
LOW🔵 Blue#5B9BD5Low risk — minimal complexity and coupling concerns.Monitor; deprioritize until higher-tier units are resolved.
DEAD_CODE⬜ Grey#9AA5B1Unit is unreachable from any entry point — never called in a known execution path.Verify with domain experts, then eliminate if confirmed unused.
TIER_ORDER in config.py defines the canonical list: ["CRITICAL", "HIGH", "MEDIUM", "LOW", "DEAD_CODE"]. This ordering governs chart axis domains, table sort defaults, and the AI Insights context sent to the model.

​
Reachability Status

In addition to a risk tier, every unit carries a Reachability Status badge visible in the Overview table and the Drill-down header. Three statuses exist:
StatusColorHexMeaning
REACHABLE🔵 Blue#5B9BD5Unit is reachable from at least one entry point in the call graph.
UNREACHABLE🔴 Red#D64545Unit has no calling path from any entry point — likely dead code.
ENTRY_POINT🟠 Orange#E8874AUnit is itself an entry point to the call graph (e.g. a program unit or exported interface).
Reachability_Status and the Priority tier are independent signals. A CRITICAL-tier unit can be UNREACHABLE — this means it carries high complexity and coupling risk but is never called in any known execution path. These are prime ELIMINATE candidates: high engineering cost to maintain, zero runtime contribution.

​
Score

Each unit has a numeric Score visible in the Overview table header column and the Drill-down metric bar. Score is the primary sort key for the prioritization report. Score is computed by Forti4D’s cross-analysis step, combining multiple signals:
  • CC — Cyclomatic Complexity (branching complexity within the unit)
  • Fan_In — number of callers (how many other units depend on this one)
  • Fan_Out — number of callees (how many units this one depends on)
  • Pct_Legacy — percentage of legacy constructs (COMMON blocks, EQUIVALENCE, implicit typing, etc.)
  • N_Common_Blocks — count of COMMON block references
  • Clone status — whether the unit is a known duplicate
  • Reachability — whether the unit is reachable from an entry point
Higher Score = higher modernization risk. The Score is normalized across the corpus, so a Score of 80 in a small project carries a different absolute meaning than 80 in a large one — always interpret Score relative to the distribution shown in the Overview bar chart.

​
Migration Strategies

Forti4D assigns a Strategy per unit, visible in the Report Explorer and Overview table. Strategies represent recommended modernization actions computed by Forti4D’s cross-analysis:
Remove this unit from the codebase entirely. Typically assigned to UNREACHABLE units with no callers. Verify with domain experts before deleting — some entry points may not be visible to static analysis.
Needs deeper investigation before a migration decision can be made. Usually assigned to units with ambiguous coupling or undetermined reachability.
Can be migrated as-is to modern Fortran with minimal structural changes. Typically low CC, low coupling, and few legacy constructs.
Replace with an equivalent standard library call (e.g., LAPACK, BLAS, or a modern intrinsic). Typically assigned to units reimplementing well-known algorithms.
Significant refactoring needed before migration. Typically assigned to units with high CC or deep COMMON block entanglement.
Rewrite from scratch. The unit is isolated enough (low Fan-In) that rewriting is safer than incremental refactoring.
Standard modernization path — update syntax and constructs to modern Fortran without structural redesign.
Strategy is computed by Forti4D before reachability is determined in a standard analysis run. A row can show a correct Reachability_Status == "UNREACHABLE" alongside a stale Strategy that doesn’t yet reflect that status. If a unit’s Reachability_Status is UNREACHABLE, consider treating its effective strategy as ELIMINATE regardless of the displayed Strategy value.
In the AI Insights view, ForTriage automatically corrects direct migration candidate counts by excluding UNREACHABLE units from the DIRECT_MIGRATION count. The KPI labelled “Direct migration candidates” reflects this corrected figure — it will be lower than a raw count of Strategy == "DIRECT_MIGRATION" rows when UNREACHABLE units exist in the corpus.

Build docs developers (and LLMs) love

Get started for freeTalk to us