Everything on this page traces to a Pulse MCP call. The instance scores 40% on runtime fitness and 35% on model fitness, and a red flag caps it at E: server memory reached 95% of RAM and six nights of backups cannot be confirmed. Four steps take it from E to A; the first one is mostly checks, not development.
instance in peak shape
lean, maintainable model
heavy technical debt
Worse of the two scales, capped at E by the red flag.
Strong availability, weak memory headroom and reliability.
Libraries in place, but broken references and idle code.
And clear both red flags: memory below 95%, backups confirmed.
Each scale is scored as a share of its maximum and graded on the same thresholds. A red flag (memory peak at or above 95%, unconfirmed backups, or uptime below 99%) caps the overall class at E.
Server memory peaked at 124,140 MB on 5 Oct, 95.1% of RAM. The 95% memory alert fired 5 times between 5 Oct 16:38 and 6 Oct 08:37 UTC. TM1 itself holds about 79,500 MB and is stable; the growth is outside TM1 (24,572 → 32,444 MB in 13 days).
get_performance_server
Pulse has no record of APQ.Server.Backup or SaveDataAll on 6 of 14 nights (24, 25, 26, 27, 30 Sep and 1 Oct). Other chores ran on those days, so it is likely a Pulse gap, but nothing proves the backups exist.
search_process_history
Model fitness is 14 of 40 (35%), inside the E band (25–39%). Even with both red flags cleared, the instance stays E until the model gains 2 more points. Runtime fitness sits exactly on the D threshold (40%): one more lost point drops it to E too.
criteria M1 to M4, R1 to R6
| Criterion | Lost | Main cause |
|---|
Each criterion has a code. R stands for Runtime fitness: how well the instance runs day to day (R1 to R6, 60 points). M stands for Model fitness: how lean and maintainable the model is (M1 to M4, 40 points). The same codes appear in the path to A, next to the points each action adds.
| Criterion | What was measured | Points |
|---|
Bonuses and penalties (source control and migration packages, chained chores, ExecuteCommand per table, logging switches inside processes, Pulse coding-rule breaches) are defined but not yet scored: they need checks the current Pulse tools do not return directly. The Python-per-table pattern seen here would cost up to 2 model points once scored.
Each step lists what to do to reach that letter from the one below it. Steps are cumulative. Open an action to see why it matters, how to do it, who does it and the effort. The minimum line is the smallest set of actions that unlocks the letter; the full plan maxes out the criteria. Projected scores assume each action fully meets its criterion.
get_performance_instance and get_performance_server (22 Sep – 6 Oct) for uptime, restarts, memory, CPU, waiting share and alerts; get_process_history for errors; search_process_history for backup runs; list_system_alerts and get_system_summary_report for monitoring.feeds: R1 to R6
list_changes since 14 Nov 2025 for the object inventory, search_source_code for cube structures and references, get_process_history (7 Sep – 7 Oct) for idle processes.feeds: M1 to M4
Each scale as a share of its maximum, graded A to G on fixed thresholds. Overall class is the worse of the two, then capped at E if a red-flag condition holds.feeds: the label
This is version 1 of the criteria and weights, applied to one instance. Total RAM is derived (about 130,500 MB). Pulse does not see processes outside TM1 or the backup files themselves. Reference checks use ranked source search, so a few references may be missed. Projected scores in the path to A assume each action fully meets its criterion; real gains may be partial. Re-run the health check before quoting a class.