Rules of credit · Earned value · EIA-748 aligned
Your register at Level 4.
Your schedule at Level 3.
Reconciled every cut-off.
Claim.Roll up.Reconcile.
Progress that traces to weighted steps and evidence, not to an opinion in a spreadsheet. EarnedCurve measures the detail your engineers actually work to, rolls it into the activity percentages your P6 programme needs, and shows you the difference — every period, computed on your own machine.
Local-first — project data never leaves the client · P6 .xer in and out · how reconciliation works →
DEMO-01 · cut-off 2026-08-31
PERIOD OPEN
Planned 66%
Earned 62%
Variance 4.3%
Deliverable
% complete
% complete
Evidence-backed
% of claims
% of claims
Awaiting review
% of claims
% of claims
SPI 0.94
L4→L3 gap 0.4%
3,842 items
◱
Claim
Weighted rules-of-credit steps per item — sliders, milestone ticks, band colour-coding. No free-typed percentages.
⌃
Roll up
Hours and value conserved from item to activity to project — an engine invariant, not a convention.
⇄
Reconcile
Step bands map L4 progress onto L3 P6 activities; variance and write-back both ways.
▤
Defend
Immutable cut-off snapshots, an evidence ledger, and a computed scope-change reconciliation block.
Why it's different
✓ Local-first — data never uploaded
✓ No per-seat licences
✓ Priced on project size, not headcount
✓ Free under 2,000 hours
The gap this closes
Two levels of truth, and no honest bridge between them
Your engineers work to a Level 4 register — documents, drawings, welds, packages, subsystems. Your programme lives at Level 3 in P6. Between the two sits a monthly negotiation: someone types a percentage into an activity, someone else disputes it, and by the time the report is signed nobody can trace the number back to anything.
⚠
Percentages nobody can trace
A 65% on an activity is an assertion. Without the weighted steps beneath it, there is nothing to audit, nothing to defend in a claim, and nothing that survives a change of personnel.
↯
Progress that silently goes backwards
Automated feeds that overwrite a claim, revisions that reset a document to zero, scope changes folded into the same number as performance. The curve moves and no one can say why.
◷
A cut-off that isn't a cut-off
If last month's figures can still change this month, the baseline is fiction and every variance is arguable. History has to be immutable or it isn't history.
The cycle
One loop, every period
Set the rules once. After that the month is mechanical: claim, close, reconcile, report.
01 / SET UP
Library
Standard disciplines, document types, RFI codes, ROC templates and work elements seed at signup. Admins publish versions; projects draw dated snapshots.
02 / PLAN
Register
Items carry a dual-basis budget — hours and value — a control account, a CAM, and a rules-of-credit template of weighted steps.
03 / MEASURE
Claim
Tick the steps that are genuinely done. Auto-claim proposes from the EDMS by document number; a person approves. Automation never applies a regression.
04 / CLOSE
Cut-off
The period snapshots. Everything before it is immutable; changes land in the open period only. The S-curve, histogram and skyline all read off the snapshot.
05 / PROVE
Reconcile
Step bands bridge L4 to the L3 activity. Scope change is separated from performance — computed, never composed — and written back to P6 or exported.
Rules of credit
Progress becomes a calculation, not a conversation
Every register item carries a template of weighted production steps. A step is either claimed or it isn't; the item's percentage falls out of the weights. That is the whole mechanism — and it is why the number is defensible six months later, in front of someone who wasn't there.
✓Weighted objective steps — the EIA-748 G7 measure, applied per item, with milestone mode for documents and ITR counts for commissioning.
✓Dual-basis budget — hours and value carried together, so the roll-up conserves both. Enforced by engine invariant tests.
✓LOE quarantine — level-of-effort is excluded from the deliverable percentage and reported separately, so it can't flatter the curve.
✓Band colour-coding — the register grid shows at a glance which items are ahead of, on, or behind their step band.
ItemProgress
PID-2140 Rev CROC · P&ID · 640 h
58%
ISO-4471-AROC · Isometric · 120 h
100%
MTO-P-0092ROC · Material take-off · 210 h
26%
SUP-PMP-014Milestone · Vendor data · 80 h
45%
PM-SUPERVISIONLOE · quarantined from deliverable %
—
ItemProgress
PFD-1100 Rev DROC · Process flow diagram · 420 h
72%
HMB-1104ROC · Heat & material balance · 260 h
100%
LDS-1210ROC · Line designation sheet · 340 h
41%
HAZOP-CLOSE-03Milestone · Action closeout · 150 h
25%
PROC-SUPERVISIONLOE · quarantined from deliverable %
—
ItemProgress
MDS-3020 Rev BROC · Mechanical datasheet · 180 h
83%
REQ-3041-PMPROC · Requisition package · 220 h
55%
VDR-3041-02Milestone · Vendor drawing review · 90 h
50%
GA-3055ROC · General arrangement · 310 h
34%
MECH-SUPERVISIONLOE · quarantined from deliverable %
—
ItemProgress
FND-4210ROC · Foundation design · 480 h
66%
REBAR-4213ROC · Rebar detailing · 260 h
12%
GEO-4001Milestone · Geotech report review · 60 h
100%
CIV-GA-4400 Rev AROC · Site GA · 350 h
47%
CIV-SUPERVISIONLOE · quarantined from deliverable %
—
Item % is derived from step weights — never typed. Rolling 3,842 items across 18 disciplines to the activity conserves hours and value to the penny.
L3 activityL4 derived · P6 held
EN-PIP-1200 Detail designband 2 of 5 · 34 items
38.4%
38%
EN-PIP-1300 Isometricsband 3 of 5 · 112 items
61.0%
60%
EN-ELE-2100 Cable schedulesband 1 of 5 · 47 items
12.2%
12%
EN-CIV-3400 Foundationsband 2 of 5 · 19 items
41.5%
40%
L3 activityL4 derived · P6 held
EN-PIP-1200 Detail designband 3 of 5 · 34 items
52.7%
52%
EN-PIP-1300 Isometricsband 4 of 5 · 112 items
84.3%
82%
EN-ELE-2100 Cable schedulesband 1 of 5 · 47 items
19.6%
30%
EN-CIV-3400 Foundationsband 3 of 5 · 19 items
63.8%
62%
L3 activityL4 derived · P6 held
EN-PIP-1200 Detail designband 3 of 5 · 34 items
61.8%
60%
EN-PIP-1300 Isometricsband 5 of 5 · 112 items
100%
95%
EN-ELE-2100 Cable schedulesband 2 of 5 · 47 items
28.4%
40%
EN-CIV-3400 Foundationsband 4 of 5 · 19 items
77.0%
75%
All four activities agree with P6 to within 1.5 points. Nothing to export — the programme and the evidence are saying the same thing.
EN-ELE-2100 opens a gap this period: P6 moved to 30% while only 19.6% of steps carry evidence. Caught at the cut-off, not at handover.
Two of four disagree. EN-ELE-2100 is carrying 40% against 28.4% of evidenced steps — an 11.6-point overstatement on 47 items. Export the correction as .xer or CSV.
The L4 → L3 bridge
P6 keeps the logic. EarnedCurve keeps it honest.
EarnedCurve never edits your schedule logic or dates — P6 owns those. What it does is derive each L3 activity's percentage from the L4 items beneath it via a step-band map you set once, then show you exactly where the programme's stated progress and the evidence part company.
✓XER import — read the activity set straight out of Primavera P6, no plugin, no server round-trip.
✓Step-band mapping — L4 steps map onto L3 bands once, per template, and derive from then on.
✓Variance view — every activity where derived and held progress disagree, sorted by the hours at stake.
✓Write-back — corrections out as CSV or .xer. You review before anything touches the programme.
Engineering & EDMS
Drop the weekly MDR. Progress derives itself.
The Engineering tab runs a weekly workflow on the same engine. Drop that week's block-format MDR export and it lands as a dated snapshot. Map each row's ROC template to step weights once, and progress derives from actual, forecast and planned dates against those weights — with a reconciliation check against the file's own reported percentage, so a disagreement surfaces immediately instead of at month end.
✓EDMS auto-claim — drop an issue-register export and it fills the actual date on auto-claim steps by document number. Manual steps, and anything it can't confidently match, are left for a person.
✓Week-on-week diff — compare two snapshots to see what slipped, went newly overdue, or completed since the prior week.
✓Your headers, our terms — a client's own column names are mapped onto industry-standard terms once, at import, and never appear again.
✓Review queue — every proposal carries its source document into an evidence ledger before it counts.
ProposalAction
ISO-4471-A → step 5 IFCmatched TRN-2026-0881 · exact doc no.
auto ✓
PID-2140 → step 4 IDCmatched TRN-2026-0902 · exact doc no.
auto ✓
ELE-CS-0071 → step 3fuzzy match · 2 candidates
review
CIV-GA-3402 Rev B → step 2would reduce claimed % (Rev A was at 5)
held
Automation proposes; humans approve. A proposal that would move an item backwards is never auto-applied — it is held for a decision and recorded either way.
Portfolio & reporting
What you get out, at every level
The Portfolio tab reads a reporting warehouse refreshed transactionally on every save — not the live documents — so a roll-up is a consistent picture of one moment, not a race between tabs.
◔
S-curve, histogram, skyline
Planned against earned per period, the period increment as a histogram, and the deliverable skyline — all read off the cut-off snapshot, all traceable to items.
◫
Printable period report
Includes the scope-change reconciliation block: what moved because work was done, and what moved because the scope changed, separated and computed.
▦
Portfolio & enterprise roll-up
Projects roll into portfolios and portfolios into an enterprise parent. Report definitions save at project scope or, for admins, at enterprise scope.
◑
Variance & forecast
SV, CV, SPI, CPI and EAC from the same evidenced numbers — the performance-measurement half of an EIA-748 EVMS.
⊞
Control account slices
Items carry a control account (WBS × OBS) and a CAM, so progress and variance slice by responsibility as well as by discipline.
⎋
Exports that keep the trace
CSV and XER write-back, plus an Excel export — each figure still tied to the items, steps and evidence that produced it.
Data & security
Local-first is an architecture, not a marketing line
Project data stays on the client. The server exists for login and billing. That is a stated, non-negotiable principle of the codebase — not a setting someone can quietly change.
⌂
Computed on your machine
The engine is pure TypeScript with zero runtime dependencies and runs in your browser. Your register, your P6 file and your EDMS export are parsed locally and never uploaded.
⊘
Never sent to an AI model
No part of your project data is sent to, processed by, or used to train any language model. Every figure is produced by deterministic, auditable code.
⛨
Tenant isolation in the database
The enterprise tier enforces row-level security on every tenant table, with the policy forced even for the table owner — isolation the application layer cannot bypass by mistake.
◈
History that can't be rewritten
Cut-off snapshots are immutable, role, approval and baseline changes land in an audit log, and contributors are scoped server-side to their assigned discipline.
Pricing
Priced on the size of the job, not the size of the team
One published price per project per month, set by the project's budget hours. Everyone who needs to claim can have a login — seats are never the meter.
Per project, per month, GBP ex-VAT. Cross a band and you get 30 days before reporting freezes — writes are never blocked, in any state. Full pricing →
Questions
The things people ask first
No, and it is designed not to. P6 owns schedule logic and dates; EarnedCurve reads them, derives Level 3 percentages from the Level 4 evidence beneath, and reports the difference. Corrections leave as CSV or .xer for you to review — nothing is pushed into your programme behind your back.
On the client. The engine is pure TypeScript with no runtime dependencies and computes in your browser; your register, P6 file and EDMS exports are parsed locally. The server handles login and billing only. This is a stated non-negotiable principle of the codebase, not a configuration option.
EarnedCurve is the performance-measurement layer of one. It produces the objective earned-value truth (rules-of-credit % → BCWP), the time-phased plan (BCWS), the variance and forecast analysis (SV, CV, SPI, CPI, EAC) and disciplined baseline control. It is deliberately not a cost-accounting or scheduling engine: your ERP owns actual costs and indirects, P6 owns schedule logic. A compliant EVMS is the combination — several of the 32 guidelines are out of scope here by design.
Two rules the engine enforces. Automation proposes and a human approves — EDMS auto-claim fills a date on auto-claim steps and routes everything else to a review queue. And a regression is never auto-applied: if a proposal would move an item backwards, it is held for a decision and recorded either way.
Changes land in the open period only; closed periods are immutable. The reconciliation block on the period report is computed, never composed — it separates the movement caused by work performed from the movement caused by the scope changing, so a growing budget can't be read as progress.
Per project, per month, by the project's budget hours: free to 2,000 hours, £199 to 10,000, £599 to 50,000, £1,499 to 250,000, £3,499 to 1,000,000, then £3,499 + £1,000 per started 500,000 hours above that — a published formula rather than a sales call. Seats are never the meter. If a project grows past its band you get 30 days of grace before reporting freezes, and writes are never blocked in any state.
Stop arguing about the percentage.
Start deriving it.
Create a workspace and run your first project through a cut-off — the whole loop, end to end.
No card required · free under 2,000 hours