Jakten Assurance User Guide

Document ID: M24-DOC-001

Audience: Estimators, commercial leads, reviewers, and project managers

Last updated: 2026-09-30

Applies to: Jakten Platform 2.0

1. What Assurance does

Jakten Assurance manages the commercial story of an estimate: its working population, packages, plan, cost model, changes, knowledge, reviews, Basis of Estimate, issue artifacts, and governed handoff to Risk.

The selected Estimate Version is the workspace boundary. Imports and edits build the current version; issued revisions, review evidence, benchmark packs, and published handoffs remain frozen historical evidence.

2. Open an Estimate Version

1. In Platform, open the project.
2. On Overview, create a working Estimate Version or select an existing one.
3. Confirm Jakten Assurance is in use on the project and you hold an Assurance seat.
4. Select Assurance.

If Assurance says the workspace is unavailable, return to Overview and select a working version. Use Back to project (top left, beside the menu button) to change projects, versions, members, drivers, or project settings. For a how-to question, select Ask Jakten in the top bar. It answers from Jakten's documentation when your company has turned on Jakten AI, and it never sends your estimate data (see the Platform User Guide, section 9).

3. Navigate with the ribbon

The Assurance ribbon is the single navigation and command surface. Its seven work areas are:

Select a work-area tab to preview its destinations, then select a destination to navigate. The ribbon also shows actions contributed by the current page. Collapse state is remembered by work area.

4. Begin in Command Center

Use Command Center to understand the selected version before editing. Review commercial totals, population coverage, metric results, package condition, and attention items.

An unavailable or missing figure is not zero. Follow its explanation or drill-through link to the source package, import, metric result, or attention item.

Recommended first checks:

1. Confirm the project and Estimate Version shown in the header.
2. Review current totals and coverage.
3. Open actionable commercial attention items.
4. Confirm the Estimate Plan and required inputs.
5. Review the Cost Model before preparing a deliverable total.

5. Plan and inputs

Use Estimate Plan to coordinate the work needed to build the version. The plan supports scheduled work, dependencies, input-deliverable tracking, and status. Accept inputs only after the received revision and responsible work item are clear.

Each row on the Schedule carries a kind and, optionally, a commercial anchor:

• Kind — Deliverable, Input, or Task — is set in the Kind column or in the row detail panel below the grid. Setting a row to Input is what puts it on the Inputs tab; the Inputs tab lists exactly the plan's input rows, so the two views never disagree. Use Add input on the Inputs tab to create one directly.
• Commercial anchor — the Package, governed figure, or commercial question the work serves — is set in the row detail panel. Choose the anchor type, supply the value it requires, then Apply anchor. Anchored rows show a chip such as Package: Civil.
• No anchor is normal. Most plan work ("develop the estimate plan", "kickoff with the client") answers to the estimate as a whole, and those rows are complete without one. Set an anchor only where it is true, and choose None to clear one. Unanchored rows are not a gap and are never flagged as such.

Tagging a long plan one row at a time does not scale, so the Schedule also works on many rows at once:

• Find the rows you want with the filter bar above the grid — by kind, status, owner, or commercial anchor. The anchor filter takes Anchored, No anchor, or a specific Package. Filtering to unanchored work is how you find the rows that *should* carry an anchor so you can add one; it is a way of finding rows, not a list of defects. Filters are remembered per Version, so a reload puts you back where you were looking.
• Add task puts the new row straight into the detail panel below the grid, selected and ready to name — and if a filter you have set would have hidden it, only the filter that was actually in the way is cleared, by name, rather than leaving you looking for a row that is there but not shown. The rest of the view you built stays exactly as it was.
• Select rows with the checkbox column, or click a row and shift-click another for a run; ctrl-click (cmd-click on Mac) adds or removes a single row. Select all takes every row currently shown. A parent row displayed only to keep a matched child in context has no checkbox and is never included.
• Apply kind, status, owner, or an anchor across the selection from the blue bar. Each row is written separately through the same governed seam as a single-row edit, so a row the system refuses is refused on its own: the summary line names which rows did not change and gives the reason for each, and the rows that did change stay changed.

Select a single row instead of several to open the row detail panel, which is where one row's kind and anchor are edited.

The Inputs tab is the same rows read a different way — every plan row of kind Input, with what each functional group owes the estimate:

• Add input creates the row here and opens its editor straight away, so you can name the input and say which Package it serves at the moment you create it. Apply anchor commits the anchor; an incomplete one (a Package anchor with no Package chosen) is refused before it is sent. If a filter would have hidden the row you just added, the filters clear themselves and say so.
• Group by arranges the register by Package, by Function, or by Nothing for one flat list. Each group heading carries its own counts — "Civil · 1 input · 1 outstanding" — which is how the register answers "what is Civil still waiting on?". Grouping only re-arranges rows; it never hides one.
• Inputs that serve the estimate as a whole, or that name a governed figure or a commercial question instead of a Package, group under No Package. That is a normal, complete state, not a gap.
• Find narrows the register by Package, by function, or by intake state. Every active Package is offered, so you can ask about one nothing is anchored to and get that answer plainly. A filter changes what is listed; the count tiles above always describe the whole register, so what the estimate is waiting on never changes because of how you are looking at it.
• Owner and Due are edited in place, one field at a time, and are written to the plan row itself — the same value the Schedule shows, because there is no second owner or due-date store. Function, state and design basis are edited the same way.
• A cancelled input still appears, labeled Cancelled, and is not counted as outstanding: work the Schedule says was called off is not work the estimate is waiting on.

An input is a schedule task and an intake record at once, so each surface shows the other:

• The Schedule's Intake column carries an input's receipt state and its latest revision — Received · Rev B — so you can read what has arrived without leaving the Gantt. A row that is not an input shows nothing there. Clicking the chip opens that input on the Inputs tab.
• Schedule on an Inputs row does the reverse. Either crossing keeps the work item selected, and so does switching tabs by hand, so you never have to find your row again.
• An input past its due date reads Late in both places, from the one due date on the work item — there is no second store to disagree with. It stops reading late once it is accepted, and a cancelled input never reads late.
• If the Inputs register cannot be reached, the Schedule still loads; only the Intake column comes up empty.

The grid is built for a plan the length of a real one:

• Every row carries its number, counted down the plan. The number is the row's name in the Logic column, and clicking it selects the row — shift-click for a run, ctrl-click (cmd-click on Mac) to add or remove one. A number counts the plan rather than the view, so it means the same thing with a filter on.
• Logic is where dependencies live, in the notation a scheduler expects: 12 for finish-to-start, 12FF for another link type, 12FS +15d for fifteen days of lag, -2d for a lead, and commas between several. This is how lag is entered, counted in the same unit as durations. Editing the cell writes only the links that actually changed — a link you did not retype is not rewritten, not even its lag unit. A cycle, a duplicate or a row number the plan does not have is refused with the reason, what you typed stays in the cell to be corrected, and nothing is deleted by an edit that was refused: the new links go in before the old ones come out, so a refusal costs nothing that was already there. An empty cell clears the row's links; a cell left holding stray commas is read as a slip and refused.
• Choose your columns. Columns on the command bar turns any of them off and moves the rest left or right — a plan with no inputs need not spend 120px on Intake. Task and its number always stay. The choice is remembered per Version, like the separator and the scale, and changes what you look at rather than what the plan says.
• The date cells show the date and nothing else; the calendar picker is still there on F4.

A plan of hundreds of rows is read one branch at a time. Every summary row carries a disclosure

triangle, and the Schedule holds a long plan to what a screen can actually show:

• Collapse a summary and its subtree comes off both panes at once — the grid rows and their bars

together. The summary itself stays, still drawing the roll-up of the children underneath it, so a

collapsed branch still says when its work starts and finishes and how far along it is.

• Collapse all and Expand all on the command bar do the whole plan. A line under the command

bar says how many rows are inside collapsed summaries, with Expand all beside it, so a plan that

is shorter than you left it never leaves you wondering where the rest went.

• Nothing is renumbered. A row's number counts the plan, so a Logic reference means the same row

whether or not the branch it is in is open. The roll-up into a summary is the same either way too:

collapsing a branch changes what you are looking at, never what the plan says.

• A selection survives a collapse. Rows you selected before collapsing the branch they are in

stay selected and stay in the next bulk write; the selection count says how many of them are

currently out of sight rather than quietly dropping them.

• Adding a task inside a collapsed branch opens that branch, and so does opening a row from the

Inputs tab — the same bargain the filters make when a new row would arrive hidden.

• What is collapsed is remembered per Version, like the separator, the scale and your columns.
• The Schedule draws the rows you can see, plus a little either side, and fills them in as you

scroll — so a 500-task plan with a web of dependencies opens and scrolls like a short one. The

scrollbar still measures the whole plan, and the page around the Schedule still never scrolls.

Links are drawn for the bars on screen; scroll and the rest arrive with them.

The Schedule fills the window. The plan takes whatever height is left under the command bar, the row detail panel sits at the foot of the screen as a single compact strip, and the plan itself is the only thing that scrolls — the page around it stays put. On a short window the plan stops shrinking at a readable minimum and the page scrolls instead of squeezing the timeline into a letterbox.

The Schedule is split between the grid on the left and the timeline on the right, and you choose how much each one gets:

• Drag the separator between them. Both panes reflow as you drag, and neither pane's horizontal scroll position moves while you do it.
• Double-click it to snap the grid to the width its columns actually want — nothing cut off, no wasted space.
• It is a control, not a decoration, so it is reachable by Tab and takes focus when you grab it. Left and right arrows nudge it, Home collapses the grid to timeline-only, and End gives the grid its full column width. A collapsed grid is restored from the same separator, which stays in place.
• The timeline always keeps a usable strip, however far right you drag.
• Your position is remembered per Version and survives a reload, including a grid you deliberately collapsed.

The timeline reads at four scales, because a two-week plan and a two-year plan are not legible at the same one:

• Day, Week, Month and Quarter. The command bar names the scale you are at, and Zoom in / Zoom out step between them — or press + and -. The ends stop rather than wrapping around.
• The date axis is two rows: an outer band naming the period (month over days, quarter over months, year over quarters) and an inner row of subdivisions. A cell too narrow for its full label shows a short one, and the axis always names at least the period you are looking at.
• Fit (or 0) picks the finest scale that shows the whole plan in the space the timeline currently has — so it answers where you put the separator, not just your window size. A Version you have never zoomed opens fitted.
• Zooming keeps your place: the day in the middle of the timeline stays in the middle, and if you have a task selected, that task is what stays put.
• The timeline always runs to the edge of the pane. The dates do not stop at the last scheduled finish — the empty weeks after your last bar are where the next task goes, so they are drawn, dated and scrollable like the rest of the calendar. Fit still measures the plan itself, so filling the pane never changes the scale it chooses.
• Today scrolls to today's date. It is offered only when today falls inside the dates on screen; a filter that hides today greys it out.
• However far you zoom out, a one-day task stays visible and stays hoverable — hovering any bar gives its title and dates.
• The scale you choose is remembered per Version and survives a reload, the same way the separator is.

The timeline carries the marks that make a schedule readable at a glance:

• A today line runs down the plot, and the axis names the date on a red chip so you know which day the line is — at quarter scale a line on its own could be any of ninety days. Both disappear when today falls outside the dates on screen.
• Weekends are shaded, so a bar that spans one visibly spans it. Shading appears at day and week scale only: a weekend is four pixels at month scale, where a stripe every fortnight reads as texture rather than as information.
• Hovering or selecting a row highlights it on both sides of the separator — the grid row and its bar together — from whichever side your pointer is on.
• The two panes scroll vertically as one, and both the column headings and the date axis stay put while the rows move under them.
• Hovering a bar gives its title, dates, duration, percent complete, owner and anchor without opening anything. A row with no owner or no anchor simply says less, rather than showing a dash.
• Nothing on this surface animates a scroll you did not ask for: Today and a zoom put you where you asked to be rather than gliding there.

A plan measured in calendar days is wrong the moment it crosses a weekend, so a Version can declare the working calendar it is scheduled against:

• Calendar on the command bar opens it. Choose the weekdays the project works — anything from Mon–Fri to a six-day week to Sunday–Thursday — and list the dates nobody works: holidays, a shutdown, a turnaround.
• With a calendar declared, durations count working days. A five-day task starting on a Thursday finishes the following Wednesday, and a task pushed out by a predecessor lands on a working day rather than on a Saturday. Lag is entered in the Logic column and counted in the same unit — working days once a calendar is declared, calendar days until then.
• Declaring a calendar does not move a single date on your plan. Dates you have already entered stay exactly where they are; the new arithmetic applies from the next edit onward. Withdrawing a calendar is equally quiet, though it does delete the holidays you declared.
• A start date you typed is never moved for you — it is yours, weekend or not. Only dates the schedule computes are placed on working days.
• Until a calendar is declared, the plan behaves exactly as it always has: durations count calendar days, and the shaded weekends on the timeline are a reading aid rather than a statement about the schedule. The line under the command bar says which of the two you are looking at.
• A duration is the distance between two dates, not a field of its own, so a row with neither cannot hold one. Type one anyway and the number stays in the cell where you put it, with a line naming the unit it was counted in and saying why it has nowhere to sit — then set a start or a finish — or link the row to a predecessor and let the schedule choose its start — and it is applied from there in one go. It is only ever applied to a row that is still blank, and only onto the single day the schedule gives a row that had no span of its own: if the row comes back carrying a span somebody chose, that span stands and the kept number is left to you to apply or clear. Declaring or withdrawing a working calendar drops it too, since five calendar days and five working days are not the same five. Clear the cell and it is forgotten rather than turning up later.
• A task that sits entirely on non-working days reads as 0 working days long, rather than being rounded up to a number its bar does not match.
• If the working calendar cannot be read, the plan still draws — but the duration column becomes read-only and says so, rather than quietly counting in a unit this Version may not use.

Once tasks are linked, the plan tells you which of them the finish date actually rests on:

• The Float column says how many days each task could slip before the project's own end date moves. A task with room prints the number; a task with none reads Critical.
• Float is counted in the same unit as durations — working days once a calendar is declared, calendar days until then.
• Critical tasks are drawn differently on the timeline: a distinct color and a heavier outline, so the reading does not depend on color alone. Hovering a bar says either *Critical path* or how much float it has.
• Hovering the Float column adds free float where it differs — the days a task can slip before the *next* task moves, as opposed to before the project's end moves. Free float is never reported as larger than total float: slack that pushes the finish date is not free.
• Critical path in the Find bar narrows the grid to that chain, and says how many tasks are on it before you choose it. Clear filters brings the rest of the plan back.
• Until you link tasks together there is no critical path, so nothing is marked critical and the filter is not offered. Float is still shown — but with no dependencies drawn, it only tells you how much earlier than the last task each one finishes. Draw the first link and the reading appears.
• A task you have cancelled shows a dash too, and never counts as critical or as the project's finish. Work the plan has called off does not get to hold the end date — a deliverable cancelled in June with June dates would otherwise become the only critical task on the plan.
• A summary row and an undated task show a dash rather than a number. A summary's dates are a roll-up of its children rather than a position in the network, and a task with no dates has nothing to be late against — printing 0 for either would read as critical.
• Nothing about float is stored. It is recomputed from your dates every time the plan is read, so it can never be stale against the plan it describes, and none of it changes a date you entered.

Not every row is a task with a length, and not every date is one the schedule chose:

• A row can be marked a milestone — a moment with no duration. "Client issues P&IDs" is a milestone, and it is also an *input*; the two are separate questions, so marking one does not change its kind. A milestone draws as a diamond on its day rather than as a bar, and it takes part in dependencies exactly like any other row.
• Marking a row a milestone collapses its finish onto its start. Turning it back into a task leaves it one day long rather than inventing a duration you did not choose.
• A row can carry one date constraint, and the two available do different jobs. Cannot start before is an input the schedule honors: a task driven by a predecessor is pushed out to meet it, and the later of the two wins. Must finish by is a deadline the schedule is measured against — it never moves a date, because a deadline that quietly pulled work earlier would be telling you what you want to hear.
• A constraint your plan already contradicts is refused, and the refusal names both dates. Setting "must finish by the 4th" on a task that finishes on the 8th does not silently record a deadline you are already missing. Nor does typing a date straight past a deadline the row already carries.
• A cascade is not refused. If a predecessor slips and pushes a task past its deadline, the write lands — you need to be able to record what actually happened — and the row says what it cost: *"Misses 2026-09-04 by 4 working days · Package: Civil"*. How late, and what it holds up.
• A deadline you are meeting says so too, quietly, rather than showing nothing. Silence there would look the same as having no deadline at all.
• Met and missed are not the only two answers. A row with no dates yet has not met its deadline — it has not been measured against one, and it says *not measured* rather than reassuring you. So does a row that has acquired children: its bar rolls up from the work underneath it, so its own dates are a leftover and measuring the deadline against them would compare it to dates nothing draws. Clear or move the constraint down to a row that holds its own dates.
• For the same reason, a row you marked a milestone stops drawing as a diamond once work is indented under it — a moment cannot contain a month. The mark is not erased: pull the children back out and it is still a milestone.
• When a plan is carrying missed deadlines, it says how many, above the grid, so they can be found without scrolling for them.

Once the plan schedules the way you mean it to, you can reschedule it on the timeline itself rather than in the date columns:

• Drag a bar to move it. The task keeps its duration — five working days stays five working days, even if it now spans a weekend — and a bar that has moved says where it is going, in dates, before you let go of it.
• Drag either end of a bar to change its duration. The other end stays exactly where it is, and an end dragged past the other one stops at a one-day task rather than turning the bar inside out.
• Drag the progress handle inside a bar to set percent complete. It is the same field as the % column, so the two can never disagree.
• Drag from a link grip to another bar to create a dependency. The grips sit just outside each end of the bar you are on; which ends you drag *from* and *to* chooses the type, so all four are reachable — finish to start is the usual one, and the bar you drop on is the successor. Cycles and duplicates are refused exactly as they are from the Predecessors column, in the same words.
• Drops land on the scale's grain, not on the pixel. At day and week scale that is a day; at month and quarter scale a day is one or two pixels wide, so drops land on whole weeks, and the line above the grid says so while you are dragging.
• A drop is your date, not the schedule's. Dropping a bar on a Saturday leaves it on the Saturday, exactly as typing that date into Start does. Only the computed end walks the working calendar.
• A driven task refuses to be moved, and says why — its start is computed from a predecessor, which is the same reason its Start field is greyed out. Change the predecessor, its lag, or the link. Its *length* is still yours: the finish edge and the progress handle both work as usual. A summary row refuses for its own reason — its dates roll up from the work underneath it — though it can still be linked, exactly as it can from the Predecessors column.
• Nothing moves until the write lands. The bar follows your pointer, the plan is written when you release, and a write the system refuses puts the bar back where it was and tells you what it refused. Press Escape mid-drag to call the whole thing off.
• Every gesture has a keyboard equivalent. Tab to a bar, then: left and right arrows move it by one grain, shift with an arrow moves the finish, alt with an arrow moves the start, up and down change percent complete by five, and L on one bar followed by L on another links them finish to start — Escape cancels a link you have started. Holding a key down does not repeat, and a press that arrives while the previous one is still saving is dropped rather than sent against a stale version: each press is its own write.

The Cost tab is where the plan meets the money. Everything on it is read from this Version's

pinned governed population — the same immutable capture Command Center and the Commercial Workspace

read — so opening it computes nothing, changes nothing, and can never disagree with them:

• The governed estimate total, and how much of it has a plan deliverable against it. Priced

scope with no deliverable is listed by Package name, as an observation rather than a fault — some

scope is priced long before anyone plans the work on it.

• What the plan's work is worth, in five figures: tracked by the plan, work complete, with late

work, work in flight, and work not scheduled. The first is the sum of the other four.

• Work nobody has placed in time gets its own figure, rather than being counted as in flight.

Calling it in flight would claim a schedule the plan has not recorded.

• Every figure says what it covers — *"3 tasks on 2 Packages"* — because each one speaks for the

work that is anchored to a Package, not for the whole estimate. Work with no Package anchor is

outside the join rather than missing from it, and is never reported as a gap.

• A Package's total is never divided across the tasks that serve it. A Package with any late work

counts in full under "with late work", and the tab says so: these are Packages with late work, not

amounts that are themselves late. Splitting a governed total across tasks would invent a figure no

line in the estimate ever stated.

• Late means a finish date that has passed on work that is not finished — stated on the tab, so

the word is never left to interpretation. Work that finished after its date is complete, not late.

Work with no finish date yet is not late either; it has not been placed in time. And a Package

whose plan work has all been cancelled is named separately rather than quietly dropped — as is one

anchored by a heading with nothing under it, which is not the same thing as a decision to stop.

• A summary row is a heading, not a task. Its children are the work, so a Package whose every

real task is finished reads as complete rather than being held open by the row that names them.

• A Package the plan names whose amount cannot be stated is counted and said out loud — not left

out of the figures silently. So is one recorded as deliberately empty, which is a governed nothing

rather than an unknown.

• Per Package: what it costs, whether its plan work is complete, late or in flight, and how many

of its tasks are done.

• A row anchored to the Version total shows the Version total. A row anchored to "a Package

total" without naming which Package says so and tells you what to anchor it to instead — an

unknown amount, never a zero.

• Where the numbers came from is named at the foot of the tab: which pinned population, at which

revision, captured when, and the day the plan's progress was read as of. A figure you cannot trace

is a figure you cannot defend in a review.

The plan's lateness reaches Commercial Attention as money, not as a to-do list. Two statements

join the Plan to the Attention surface, and both are read from the same pinned governed population

the Cost tab reads:

• Overdue inputs, and the priced scope waiting on them — *"4 input deliverables are overdue, and

$1,000,000 of priced scope is waiting on them (Civil, Structural)."* One statement for the Version:

which row is late is what the Plan is for, and Attention already lists each late commitment

separately. The scope waiting on an overdue input is reported in whichever of four states it is

actually in, because they are four different facts: priced (in money), recorded as deliberately

empty (a decision, not missing data), an amount that could not be established (unknown rather than

zero), or no Package at all. Folding them together would report a governed zero as a gap.

• Late work on the critical path, and what it gates — *"'Civil pricing' was due to finish

2026-07-10 … and it is on the critical path — so it gates $1,000,000 of priced scope across 2

Packages (Civil, Structural), and the 1 row waiting behind it."* What a task *serves* is its own

Package; what it *gates* is that plus the Packages served by everything waiting behind it, because

a delay does not stop at the row that caused it. Late work that is not driving the finish date

states nothing here — the Plan already shows it is late.

• A Package counts whole, and once. Two overdue inputs on the same Package do not count it twice,

and a Package's total is never split across the tasks that serve it.

• No anchor, no dollar claim. A late task with no commercial anchor, and nothing anchored behind

it, raises no money statement at all. It is still late and still on the Plan; putting a number on it

would mean inventing the anchor it does not have.

• If the reading behind these figures cannot be established, they are **withheld rather than shown as

zero**, the Packages they touch read as *unknown* rather than clear, and the plain "this commitment

is overdue" still appears.

Project Drivers are maintained in Platform. Assurance uses those values for normalized knowledge and company metrics; if a rate is unavailable, confirm the required driver exists rather than entering a substitute zero.

6. Import and manage Packages

Use Commercial → Packages for the authoritative commercial population.

Typical workflow:

1. Create or open the destination package.
2. Import an Excel or CSV estimate, or edit supported line details in the package workspace.
3. Map required fields and classifications.
4. Review warnings, unmatched classifications, units, and monetary values.
5. Commit the import.
6. Reopen the package and confirm totals, counts, coverage, and source identity.

Use Import History to inspect committed imports and their status. A later import does not silently erase frozen history. Correct working data through the supported package and import actions.

Package detail brings together line items, commercial rollups, labor economics, variance, change exposure, history, knowledge, and review context. Use the package drill-through rather than copying totals into an external summary.

7. Build the Cost Model

Use Cost Model to build from governed direct cost into the loaded project total. Rows can represent percentages, lump sums, subtotals, and permitted module references such as a published Risk contingency result.

Review every unavailable module reference. Assurance will not invent a value when a required Risk publication or other basis is missing.

When pending changes are present, the workspace may show a forecast overlay. That overlay supports decisions; it does not rewrite the committed estimate population.

To carry an accepted additive change in the loaded total, choose Move to Cost Model beside it in the overlay. The Cost Model must be on and the change must have a cost. The change becomes the last row of the sheet, labeled Accepted change, and leaves the pending total, so it is never counted twice. Its amount is the change's cost when you moved it:

• If the change is re-estimated, the row keeps its amount and is flagged; choose Refresh to bring in the new figure. The amount cannot be typed over.
• If the change is rejected, reclassified as already in the estimate basis, or deleted, the row stays and is flagged; remove it yourself if it should no longer be added.
• A moved change raises the loaded total only. It is not added to direct cost or to cost-type and WBS breakdowns, and a percentage row based on direct cost does not mark it up.
• Removing the row returns the change to the pending total. Save as company default leaves change rows out.

8. Manage changes and should-cost work

Use Change / Trend Register to capture a change, move it through its commercial status, connect it to affected packages, estimate its cost, apply markup, and classify whether it is already incorporated, additive, or still undetermined.

Use Should-Cost Register for procurement packages, quote comparison, vendor or internal should-cost inputs, variance analysis, and workflow status. The register is project-scoped and can span Estimate Versions; confirm the version and package context before importing or comparing.

Open exposures must remain visible until they are resolved or intentionally incorporated. Do not manually add a change to totals without recording its package and reconciliation treatment.

9. Compare Evolution

Use Estimate Evolution and Commercial Deltas to compare saved version evidence. Choose the intended earlier and later versions, then review the comparison basis before interpreting totals or changed lines.

Comparisons use frozen version evidence. If a comparison is unavailable, one side lacks the required saved artifact; unavailable does not mean no change.

Use Timeline for the commercial sequence and historical events around the version.

10. Use Knowledge and Standard Metrics

Version Knowledge surfaces relevant historical commercial evidence and reasonableness context for the current work.

Standard Metrics contains the governed metric library and the values applied to the version. Published company standard metrics are applied through the governed estimate-state workflow; users do not manually activate metrics on a project. Review definitions, values, citations, and unavailable reasons before promoting a result into a Finding.

Knowledge suggestions support professional judgment. Confirm applicability and source context before relying on a benchmark or rate.

11. Run a Version Review

Open Reviews to prepare and conduct a governed commercial review. The guided workflow supports:

1. Preparing the review basis
2. Reviewing required content and risk evidence
3. Recording findings, decisions, and actions
4. Preparing the presentation
5. Presenting from a frozen session basis
6. Issuing the review artifact

Resolve blocking validation before issue. If the estimate basis changes after preparation, refresh or create the appropriate review evidence instead of presenting a stale basis.

12. Maintain the Living BoE

Use Living BoE to compose the Basis of Estimate from structured, cited evidence and authored narrative. You can arrange governed sections, add custom sections or text blocks, insert supported package evidence, and review cost, coverage, change-trend, and project build-up content.

Draft edits are not the same as an issued revision. Review the composed document, citations, and displayed totals before issuing PDF or Word output.

13. Deliver and publish

Use Deliver for final preparation:

Assemble shows delivery gates, which are advisory — they describe the estimate, and none of them blocks you from assembling a draft. Inputs accepted counts the inputs still owed using the same rule as the Inputs tab: Accepted settles an input, every other state means it is still owed, and an input whose plan work item was cancelled is not counted on either surface. Where cancelled inputs exist the gate says how many it left out, so the count can be reconciled against the plan. Cancelling work you are genuinely no longer waiting for is the way to clear it — never recording acceptance of a deliverable that was called off.

Before issue or publication, confirm the displayed project, version, basis, population coverage, and validation state. Publishing to Risk creates a governed handoff; it does not grant permission to alter a completed Risk simulation in place.

14. Common problems

Related documentation