Most systems can tell you what a project reported. Flowr holds the business case, the baseline, the plan, submitted time, the approved budget and the forecast on one record, and produces the status report from them — so the position a project claims can be checked against the evidence it came from.

Control usually ends up spread across systems that were each a sensible choice on their own. None of them is wrong. They simply have no way of contradicting one another, so nothing does.
A project can report Green through every one of those steps and still be over. Not because anyone lied — because no two of the five numbers were ever asked to reconcile.
Flowr is not four tools with connectors between them. The business case, the baseline, delivery, effort, cost, forecast and reporting are stages of one project record, so each stage is measured against the one before it rather than against a copy of it.
Each stage is checked against the one before it, not against a copy.
The business case is snapshotted at approval rather than overwritten, so closure has something to compare against. The baseline is kept beside the live plan for the same reason. Submitted time becomes actual cost at the rate in force on the date it was worked — so a rate change next month does not rewrite what last month cost.
Because timesheets and the plan sit on the same record, Flowr can compare what a project has spent with what it says it has finished. When those two diverge, it says so, and names the tasks that caused it.
This is advisory, and deliberately so. A project 94% through its effort at 66% reported progress may be badly estimated, front-loaded, or genuinely in trouble; Flowr does not know which. It raises the question early enough to be worth asking and puts the evidence next to it. The project manager still answers it.
Approved budget, actual cost, estimate to complete and estimate at completion in one model, with variance computed against two references — because being over the plan and being over the approved budget are different problems with different escalation paths.

Every labour cost traces to submitted time, the rate in force on that date, and a period closed on a specific day.
Work Flowr cannot cost is reported as uncosted exposure rather than quietly counted as nothing.
Override the modelled EAC and it is stored with a reason and an author, not applied as a silent edit.
Tolerances are set for the organisation, not per project, so amber means the same thing everywhere and portfolio status is comparable. Warning and critical are separate numbers, because deciding to watch something and deciding to stop it are separate decisions.

The project control assistant applies your thresholds to the project record and shows the evidence behind each signal. It is deterministic, so the conversation starts at what to do rather than at whether it is right.
Acknowledge a control issue with a recorded reason, assign it to a person, and clear it when it is resolved. Either way the answer stays on the record.
Which stages need a decision before work continues comes from an organisation template, not from a convention people are expected to remember.
Fifteen PRINCE2 and PMI roles ship ready to assign. Naming someone Project Assurance lets them see the project; it does not let them edit or approve anything.
The monthly status report is assembled from the same project data everything else on this page describes — milestones, risks, progress, effort, cost and forecast — and then edited and signed by the project manager. It is not a separate document that has to be kept in step with the project by hand.

Portfolio budget, timeline and cross-project milestones are computed from live project data. There is no separate portfolio model to maintain, and therefore no month in which the two quietly stop agreeing.

The fastest way to judge a control system is to point it at a project whose real position you can already argue about. Early access is granted one workspace at a time so we can set it up against yours.