$ agit // control plane
Trust in the numbers · Altered Graph.it

Why the numbers can be trusted

AG.it is a control plane where a project's state isn't reported — it's computed. Every number on the screen is a promise of trust, so this page is honest about it: what gets computed, what makes a number true, and where a number rests on a human decision rather than a bare fact.

“Project state is computed from facts — and the interface proves it.”

The promise

Status, money and risk aren't what someone wrote about themselves. They are derived from three kinds of facts and recomputed from scratch on every change.

Tasks
A snapshot of the project's tasks on a date — what closed, what's overdue, what started. State is built from the snapshot, like a build from a commit.
Signals
An append-only stream of events: an acceptance confirmation, an expense, a deadline shift with a reason, a soft signal like “client scheduled acceptance”. Records aren't edited — changes are added as a new event.
Accepted milestones
Money becomes “revenue” only once a milestone is accepted — the act is signed. Not “80% done”, but “act signed, payment closed”.

Any number opens up to its cause: the verdict shows an evidence line (“N tasks closed · M/K goals accepted”), and every change in the diff stands on the date of a fact or a signal. If data is missing, it says so in words — it never substitutes a plausible zero.

What is computed, and how

The key indicators a buyer cares about. For each: what it means, and what makes it true. Money is always kept separate by currency — rubles and dollars are never merged into one total.

Revenuemoney

The sum over milestones that are already accepted. This is money whose outcome is locked in.

True when: the milestone is accepted — the act is signed (or acceptance is explicitly confirmed by a person). Until the act exists, money doesn't land here, no matter how many tasks are closed.

Backlogmoney

The sum over money milestones not yet accepted. Money in flight: the outcome may be nearly done, but the act isn't signed.

True when: a milestone has money and a deadline but no acceptance yet. “Revenue + backlog” = the project's entire money figure.

At riskmoney

The part of “backlog” flagged red: money that may not arrive. It's a subset of backlog, not a separate sum on top.

True when: an unaccepted money milestone is blocked, marked at-risk, or its deadline has already passed. A passed deadline counts as a threat even if the work is on track — deliberately cautious, in favour of early warning.

Delay

How many days the project is behind plan. Highlighted in the header and the verdict line.

True when: computed from task dates — it's the largest delay across tasks (the most overdue one sets the bar), not an average. A direct read from planned dates, no manual estimate.

Progress

The share of closed tasks. Useful as a pace of work, but on its own it isn't money — which is why the money read, not the percentage, always leads.

True when: computed as the percentage of closed tasks out of active ones (cancelled tasks are excluded from the denominator). It's about activity; “80% done” says nothing without a money read beside it.

Project status

The project's traffic light: on track · risk · danger. The same criterion for the project card and the portfolio register.

True when: derived from facts — a blocked goal or a large delay → danger; an at-risk goal, a meaningful delay, or a new risk → risk; otherwise on track. A green chip can't sit above a “money at risk” banner — the worse of the two is taken.

Verdict

A one-line diagnosis: what matters now (“Money at risk — outcome not locked in”). Beneath it, an evidence line built from facts.

True when: chosen by a strict rule priority — instrument failure and blockers first, then delay, unclosed money, new risks. The evidence (“N tasks closed · M/K goals accepted”) keeps the verdict on facts, not on phrasing.

What changed · diff

The difference between two snapshots: what's achieved, what slipped, which signals arrived. Every change with an actual date.

True when: two plan snapshots and the signal stream between them are reconciled. Separately: where a human “done” is confirmed by the authoritative snapshot, and where it's contradicted.

Plan health

An “N findings” chip in the header: a goal without an acceptance criterion, a milestone without an amount, a dangling dependency, accumulated deadline shifts. Not work status — the quality of the model itself.

True when: the linter has run over the plan structure and the goal graph from a single source. Findings are conservative — better to stay silent than raise a false alarm.

Data freshness

When the latest snapshot was taken. A project is flagged “stale” if the snapshot is over a week old — so you know which moment you're looking at.

True when: the whole plane is computed from one time axis. You can rewind to any date (time-travel) — state is rebuilt from snapshots as it was then, reproducibly.

Honest caveats

Where a number rests on something other than a clean external fact, we say so plainly. This is a matter of integrity, not a defect: trust in a number should be graduated.

“Accepted” can be a human confirmation
Ideally “revenue” rests on an external fact — a signed act, a bank statement, EDI. But acceptance is confirmed by a person, and sometimes “accepted” is their explicit confirmation rather than an auto-read payment. This is by design: a human, not a bot painting green, owns the criterion of truth. That's why the goal of the display is to distinguish “accepted by a human” from “confirmed by an external fact”.
The EN view re-prices rubles into €/$ at a fixed ratedemo rate
In the Russian view, amounts are in the project's currency (rubles). In the English view, demo data is re-priced into euros/dollars at a fixed demonstration rate, not the rate of the day. That's convenient for a demo, but the €/$ figure in the demo is approximate, not a market rate. On a real rollout the project's currency is kept as-is.
“At risk” is cautious by construction
A money milestone with a passed deadline falls “at risk” even if the work is formally on track. We deliberately lean toward early warning: better to show the risk early than learn of an acceptance slip after the fact.
Delay is the worst task, not an average
“Delay +N days” is the largest delay across the project's tasks: the most overdue one sets the bar. That way the banner isn't diluted by averaging and shows the real edge of risk.
Progress is pace, not outcome
The percentage of closed tasks is useful, but it is not money and doesn't mean “done”. So it never leads the picture alone — there's always a money read beside it: revenue / backlog / at risk.
Input quality = model quality
A metric labels its own strength honestly: “strong signal”, “weak”, “proxy”, “no data”. If an indicator measures the goal only partially, a caveat says so right on the goal card. We don't pass a weak signal off as a precise measurement.

What you'll never see

A few rules we hold firmly — these are what separate a control plane from a pretty dashboard.

Want to see this live — the owner scenario walks the same screens step by step, on live demo data.

If you meet a term

Snapshot — a snapshot of the project's tasks on a date; state is computed from it — like a build from a commit.
Milestone — a goal with money and a deadline: its acceptance is what gets paid, by act.
Revenue / Backlog — money on accepted milestones (act signed) / on not-yet-accepted ones (pending acceptance criteria).
Acceptance — a confirmation that a milestone was accepted (a record in the acceptance log), with a date and a basis.
Signal — an append-only event: a confirmation, an expense, a deadline shift with a reason, a soft signal.
Diff — what changed between two snapshots: what's done, what slipped, what's at risk.