DekEn
All showcases

Project Console · Earned Value

One Project, Every Function

A 12-document carbonation-pilot register run end-to-end: paste it from Excel, let IFR/IFA/IFC status gates drive the percent, pull open HAZOP actions onto the Gantt, and read an earned-value S-curve replayed from an append-only change log.

41.9%
earned value across 12 weighted documents — Σ(weight × %) / Σweight = 880/2100
30% vs 41.9%
planned vs actual on the S-curve — this example runs ahead of its dated plan

The example

A carbonation-pilot register, start to Monday morning

One project carries the whole story: a document register pasted straight from Excel, status gates that turn document lifecycle into percent, actions pulled in from a HAZOP study on the same platform, and a dashboard whose actual S-curve is replayed from the change log — not typed into it. Everything below is visible, read-only, in the live example workspace.

Project
Carbonation Pilot — Unit 14
Register
12 documents · 3 disciplines · Σweight 21
Schedule
6 actions · 2 milestones on one Gantt
Wired to
2 linked assets (hydraulic model + HAZOP study) · 3 members

The journey

Ten steps, every v1 function once

Read it as a workflow: each row is one function of the console, the figure it produces in this example, and where that figure comes from.

The end-to-end journey through every function
ParameterValueWhat it proves
1 · Create the projectowner / editor / viewerA subscriber creates it; sharing works by email and members ride along on any signed-in account — editors write, viewers read (pinned by the backend permission-matrix tests).
2 · Paste the register from Excel12 rows in one pasteCopy the document register from Excel and paste once — the parser validates status and dates line-by-line, with 1-based line numbers on every rejected row, before anything is created.
3 · Status gates drive the percentIFR 30 · IFA 60 · IFC 90Flip a document to IFA and its percent recomputes from the project’s own gate rules (editable per project). Manual overrides live between gates; the next gate change reclaims the number.
4 · Earned value rolls up41.9%Σ(weight × %) / Σweight = 880/2100 — the same golden-tested backend engine (core/pm_progress.py) every real project runs through.
5 · Every change is an event7 weekly pointsStatus and percent changes append to an event log that is never overwritten — the actual S-curve is literally a replay of that log, not a number anyone typed.
6 · Schedule on one Gantt6 actions · 2 milestonesTasks grouped by discipline, milestone diamonds, and document due-dates share one timeline; done work recedes, blocked work stands out, today is a line you can see.
7 · Import actions from the HAZOPimported 1 · skipped 1Open PHA register rows become tasks 1:1 with a back-link to the study; re-import skips what already exists (idempotent on the source row). The figure is from the live click-through on this stack.
8 · Link the engineering2 linked assetsPointers to the hydraulic model and the HAZOP study that already live on this platform — one click across, title snapshots survive renames.
9 · Share the workspace3 membersOwner shares by email; only the owner manages permissions. A read-only viewer sees exactly this demo’s experience.
10 · Read the dashboard3 overdue · 1 unscheduledServer-computed roll-ups: planned-vs-actual S-curve, per-discipline progress, and the overdue register — the page a project lead opens on Monday morning.

What this proves vs the competition

The Excel-register + MS-Project pair, replaced — on the same platform as the HAZOP. The register lives where the engineering lives: the HAZOP that generates the actions and the hydraulic model the documents describe are one click away, on the same login — no export, no re-typing, no second tool to keep honest.