Every distinct view in oxFlow v1 — the screen list that prototypes will build against. Each view is defined by its purpose, primary user(s), key content, and key interactions.

How to read this doc:

  • Views are grouped by the area of the product they belong to.
  • “Primary user” uses the role taxonomy in foundation/roles-permissions.md.
  • Key interactions describe what the user does on this view, not the underlying data model.

Related: estimator-journey.md · navigation.md · entity specs in entities/


Summary

#ViewAreaPrimary userFidelity target
1Home / DashboardGlobalAll rolesMedium
2Tenders listWork hierarchyLead Estimator · EstimatorMedium
3Tender detailWork hierarchyLead EstimatorMedium
4Estimates list (in Tender)Work hierarchyLead Estimator · EstimatorLow
5Estimate EditorWork hierarchyEstimator · Lead EstimatorHigh (prototype)
6Worksheet EditorWork hierarchyEstimator · Lead EstimatorHigh (prototype)
7Program linkerWork hierarchyLead Estimator · EstimatorMedium
8Price Books listPricing & procurementAll rolesLow
9Price Book EditorPricing & procurementLead Estimator · AdminMedium
10Price Book Adjudication (six-step)Pricing & procurementEstimator · Lead EstimatorHigh (prototype)
11Subcontract Packages list (in Estimate)Pricing & procurementEstimator · Lead EstimatorLow
12Subcontract Package Adjudication (six-step)Pricing & procurementEstimator · Lead EstimatorHigh (prototype)
13Commercials (Rules + Submission Values)Commercials & submissionLead EstimatorHigh (prototype)
14PublisherCommercials & submissionLead Estimator · AdminHigh (prototype)
15Anomaly DashboardCross-cuttingEstimator · Lead EstimatorHigh (prototype)
16Recipe LibraryBuilding blocksAll rolesMedium
17Recipe BuilderBuilding blocksEstimator · Lead EstimatorHigh (prototype)
18Admin — Users & RolesAdminAdminLow
19Admin — UnitsAdminLead Estimator · AdminLow
20Admin — CategorizationsAdminLead Estimator · AdminLow
21Admin — Flag CatalogAdminLead Estimator · AdminLow
22Admin — Modifier CatalogAdminLead Estimator · AdminLow
23Admin — CodesAdminAdminLow
24Admin — Reference RatesAdminLead Estimator · AdminLow
25Admin — Content Block DefinitionsAdminAdminLow
26Admin — BrandingAdminLead Estimator · AdminLow
27Admin — IntegrationsAdminAdminLow
28Audit / Activity logCross-cuttingAdminLow

28 views total. 10 marked for high-fidelity prototyping; 5 medium; the rest low-fi or spec-only (standard list / form / table shapes).


Global

1. Home / Dashboard

Purpose: landing view after login. Fast access to active work and cross-Tender signals.

Primary user: All roles.

Key content:

  • My active Estimates (where I’m Lead Estimator or recently edited)
  • Tenders nearing due date
  • Anomaly counts across my active Estimates
  • Recently viewed
  • Quick-create: New Tender, New Estimate (scoped if I’m inside a Tender)

Key interactions:

  • Click into a Tender / Estimate
  • Jump to Anomaly Dashboard filtered to my work
  • Search bar (Tender number, Estimate name, Item description, Resource name)

Work hierarchy

2. Tenders list

Purpose: browse all Tenders in the workspace; filter by status, Client, due date, Categorization.

Primary user: Lead Estimator · Estimator (read) · Admin.

Key content:

  • Table: Tender name · number · Client · location · due date · status · win probability · Lead Estimator · Estimate count
  • Filters: status, date range, Client, Categorization
  • Sort: due date (default), created, updated

Key interactions:

  • Create Tender (Admin + Lead Estimator)
  • Click row → Tender detail
  • Bulk archive (Admin + Lead Estimator)
  • Export list (CSV)

3. Tender detail

Purpose: single-Tender home — metadata, Estimate list, Program upload, state transitions.

Primary user: Lead Estimator.

Key content:

  • Tender metadata panel: name, number, Client (linked), client reference, location, contract start date, tender due date, win probability, status, Categorization tags, notes
  • Estimates panel: list of child Estimates with status, Lead Estimator, total cost, Submission Value total
  • Tender Program panel: uploaded file (name, version, parse status, task count), re-upload action
  • State transition controls: Submit (cascade from Publisher), Won, Lost, Archive

Key interactions:

  • Edit Tender metadata (Admin + Lead Estimator)
  • Upload / replace Tender Program (Admin + Lead Estimator)
  • Create Estimate (Admin + Lead Estimator)
  • Manual state transitions (Admin + Lead Estimator)
  • View parse errors (if Tender Program failed)

4. Estimates list (in Tender)

Purpose: compact list of Estimates inside a Tender.

Primary user: Lead Estimator · Estimator.

Key content: Estimate name · number · Lead Estimator · status · total cost · Submission Value total · updated date.

Key interactions:

  • Click → Estimate Editor
  • Create Estimate (Admin + Lead Estimator)
  • Archive (Admin + Lead Estimator)

Fidelity note: standard list pattern; low-fi sufficient.


5. Estimate Editor ⭐ prototype

Purpose: the daily driver. Tree-based view of all Headings and Items in an Estimate, with per-row cost and status.

Primary user: Estimator (build-up) · Lead Estimator (review, sign-off).

Key content:

  • Tree pane (left or full-width): Heading and Item hierarchy up to 5 levels each, with expand / collapse.
  • Per row: description, code (schedule code), unit, quantity, unit cost, total cost, Item Type badge, Item status badge (Unpriced / Plugged / Priced / Reviewed / Locked), anomaly indicator, Workcentre Code
  • Sidebar (right, context-sensitive): when an Item is selected, shows its summary, Worksheet preview / open button, Categorization tags, linked Program Tasks, Commercials Rules that match, Anomaly flags
  • Header bar: Estimate name, version, Lead Estimator, status badge, totals (Direct / Indirect / Total), primary actions (Open Adjudication, Open Commercials, Open Publisher, Run Anomaly Review)

Key interactions:

  • Add Heading / sub-Heading (depth capped at 5)
  • Add Item under any Heading or Item parent (depth capped at 5)
  • Reorder (drag and drop; respects Schedule Item positioning rules)
  • Inline edit (description, code, quantity, unit, Item Type, flags, Workcentre)
  • Open Item → Worksheet Editor (view 6)
  • Set Item status Priced → Reviewed (Lead Estimator / Admin)
  • Bulk Categorize / bulk set Item Type
  • Duplicate Item
  • Delete (confirm cascade behaviour)
  • Assign Estimator (informational, Admin + Lead Estimator)
  • Concurrency indicators — “editing: [User]” per row

6. Worksheet Editor ⭐ prototype (highest risk)

Purpose: the “show your work” surface for one Item (or one Recipe when opened from the Recipe Builder). Where methodology, quantities, resources, and rates come together.

Primary user: Estimator.

Key content:

  • Parent Item (or Recipe) summary: description, unit, quantity, Item Type, status
  • Variables pane: list with name · value/expression · unit · origin badge (Manual / Program Task / Calculation / Input Parameter)
  • Calculation Blocks pane: name · expression · resulting value
  • Worksheet Resources pane: for each WR — Resource name, quantity (expression allowed), snapshot rate, snapshot unit, snapshot flags, modifier values (with defaults from Resource), wastage factor, notes, divergence indicator, row cost
  • Worksheet Recipes pane: for each WRec — Recipe name, Input Parameter values (key/value), snapshot reference, evaluated cost
  • Content Blocks pane: per definition (Inclusions, Exclusions, Task Breakdown, Risks, plus admin-defined) — free text editor
  • Right rail (contextual): Item total cost, unit cost, plug_rate toggle, status derivation explanation, anomaly flags for this Worksheet, rate-divergence banner with push-through action, linked Program Tasks

Key interactions:

  • Drag Resource from Price Book picker → creates Worksheet Resource (freezes snapshot)
  • Drag Recipe from Recipe Library picker → creates Worksheet Recipe with Input Parameter prompts
  • Add / edit / reorder Variables (names unique within Worksheet)
  • Add / edit / reorder Calculation Blocks (expressions reference Variables or other Blocks by name; well-formedness validated)
  • Edit Worksheet Resource quantity, wastage, notes, modifier values
  • Rate edit actions: Per-instance override (default), Apply to this Estimate, Fork to new Resource — see sub-flows/rate-edit-mechanics.md
  • Push-through action on diverged snapshots (accept new Resource rate / flags / modifier defaults)
  • Set / clear plug_rate on parent Item (triggers status derivation)
  • Link Program Task → creates Dur_{TaskName} Variable
  • Edit Content Blocks (free text; admin-defined instructions shown inline)
  • Modifier per-instance override

Risk flags: the most novel view in oxFlow. Clear rendering of snapshot vs live state, rate-edit action semantics, and expression validity is critical.


7. Program linker

Purpose: upload / re-upload MS Project files; map Program Tasks to Items.

Primary user: Lead Estimator · Estimator.

Key content:

  • Upload dropzone (if no Tender Program yet) or file summary (if one is attached)
  • Parse status badge and error detail (if failed)
  • Program Task tree (summary + subtasks; surfaces summary task duration only)
  • Per-task: name, start, end, duration, is_summary_task flag, linked-Item count
  • Right pane: selected Task’s linked Items list, add-link picker (Item picker)

Key interactions:

  • Upload .mpp → triggers parse (confirms format; other formats flagged)
  • On re-upload, Import Wizard mediates reconciliation: same Task ID = update, new Task ID = new task, missing = orphan flag
  • Link Task to Item (creates Dur_{TaskName} Variable)
  • Unlink Task from Item

Pricing & procurement

8. Price Books list

Purpose: browse all user-created Price Books. System-generated ones are hidden by default; toggleable.

Primary user: all roles.

Key content:

  • Table: name · type (Project-Specific / Internal / External) · supplier (if External) · scope date range · scope region · status (Active / Archived) · resource count
  • Filters: type, supplier, status (Active default), region
  • Toggle: “Show system-generated Price Books”

Key interactions:

  • Create Price Book (type-gated per roles matrix — Internal is Admin / Lead Estimator only)
  • Click → Price Book Editor
  • Archive / unarchive (Admin; auto-archive at scope_end_date)

9. Price Book Editor

Purpose: view / edit one Price Book and its Resources.

Primary user: Lead Estimator · Admin (and Estimator for Project-Specific / External per roles matrix).

Key content:

  • Metadata panel: name, type, source type (user / adjudication), supplier (if External), project (if Project-Specific), scope date range, scope region, description, status
  • Lineage badge if system-generated: links to producing Subcontract Package Adjudication
  • Resources table: description · rate · unit · Resource Type · flags · modifiers · Categorization · Activity Code
  • Filters: Resource Type, Categorization, has flag, search

Key interactions:

  • Add / edit / delete Resource (gated by Source Type — system-generated is read-only)
  • Duplicate Resource
  • Bulk Categorize / tag
  • Archive Price Book (manual)
  • Navigate to source Adjudication (for system-generated)

10. Price Book Adjudication ⭐ prototype (shared with SPA)

Purpose: run a six-step Price Book Adjudication. One flavour of the shared Adjudication workflow; shares layout with SPA.

Primary user: Estimator · Lead Estimator.

Key content: six sections matching the steps (tabs or vertical stepper):

  1. Generate — scope builder: pick Resources from the Estimate’s Price Books; shows baseline rates; count of selected Resources
  2. Export — export package (Excel / PDF) with baseline rates + return instructions; track sent-to list
  3. Import — per-supplier return upload via Import Wizard: column mapping, preview, validation errors
  4. Compare — side-by-side matrix: baseline vs each supplier’s return, variance per row
  5. Normalise — add normalisation rows (transient) — e.g., fill a missing rate using Supplier A’s equivalent
  6. Transfer — award: pick winning supplier; system replaces scoped Resource rates in place

Key interactions:

  • Progress between steps (Draft throughout until Transfer completes)
  • Add / remove supplier Returns (role validation at first-gate)
  • Capture variance / inclusion / exclusion notes → saved as Content Block instances on affected Items
  • Add normalisation row (editable; not persisted to Resources)
  • Re-open (Adjudicated → Draft; gated by Estimate state) — starts a new round

See sub-flows/price-book-adjudication.md.


11. Subcontract Packages list (in Estimate)

Purpose: list Subcontract Packages for the current Estimate.

Primary user: Estimator · Lead Estimator.

Key content: name · scope description · item count · latest adjudication status (Draft / Adjudicated) · latest awarded Subcontractor · total awarded value · round count.

Key interactions:

  • Create Subcontract Package (atomically creates its first Adjudication in Draft)
  • Click → Subcontract Package Adjudication view
  • Edit Package Items (gated: only while latest Adjudication is Draft)

12. Subcontract Package Adjudication ⭐ prototype (shared with PBA)

Purpose: run a six-step Adjudication over an Item bundle.

Primary user: Estimator · Lead Estimator.

Key content: same six-step layout as view 10. Differences:

  • Generate — scope is the Package’s Item set (not Resources); picker to adjust Item membership (only while Draft)
  • Export — per-Item line items (description, quantity, unit)
  • Transfer — on award, creates / updates the Package’s system-generated Price Book with one Subcontract Resource per Item and links each Item’s Worksheet to it

Key interactions:

  • Same as PBA, with Package-scoped Items instead of Resources
  • Re-open (Adjudicated → Draft) — starts a new round; system-generated Price Book persists across rounds

See sub-flows/subcontract-package-adjudication.md.


Commercials & submission

13. Commercials ⭐ prototype

Purpose: add sequenced Rules; review computed Submission Values; override before publish.

Primary user: Lead Estimator.

Key content:

  • Rules pane (top): ordered list of Rules — name · rule type (Percentage / Lump Sum) · value · scope targets summary · sequence order · running running-state indicator
  • Totals pane (middle): running totals after each Rule — Direct · Indirect · Total · Margin effective
  • Submission Values pane (bottom): per Schedule Item — description · unit · quantity · computed value · override value (editable) · final value · audit notes
  • Scope pane (contextual when editing a Rule): scope target picker (All / Direct-only / Indirect-only / Heading subtree / Item Type / Resource Type / Categorization Option / Code value / specific Item)

Key interactions:

  • Add / edit / delete Rule (Lead Estimator + Admin)
  • Reorder Rules (drag — changes final totals)
  • Edit scope targets
  • Override a Submission Value (with audit note)
  • Clear an override (reverts to computed)
  • Jump to affected Item (Estimate Editor)

See sub-flows/commercials.md.


14. Publisher ⭐ prototype

Purpose: preview and publish the client-submittable artifact.

Primary user: Lead Estimator · Admin.

Key content:

  • Preview pane: rendered output — branding header, cover letter, Schedule table, Submission Values, conditions, inclusions, exclusions
  • Editor panels (side):
  • Cover letter editor (rich text)
  • Conditions editor (rich text)
  • Inclusions / Exclusions editors
  • Branding config (logo, colours, fonts — from admin config)
  • File format picker (PDF / Excel)
  • Submit gate status: clean vs blocking-Item list

Key interactions:

  • Edit cover letter, conditions, inclusions, exclusions
  • Preview output (re-renders as edits happen)
  • Publish — gated by the Submit check; on success: Publisher Output → Published, Estimate → Submitted, Items → Locked
  • Download latest published artifact
  • Republish (replaces prior artifact)

Building blocks

16. Recipe Library

Purpose: browse all Recipes available across the workspace.

Primary user: all roles.

Key content: name · description · output unit · input parameter count · Categorization tags · created by · last updated · usage count (Worksheet Recipes across all Estimates).

Filters: Categorization, Output Unit, created by, search.

Key interactions:

  • Create Recipe (Estimator + Lead Estimator + Admin)
  • Click → Recipe Builder
  • Archive / delete (Lead Estimator + Admin)
  • Duplicate

17. Recipe Builder ⭐ prototype

Purpose: create or edit a Recipe. Structurally similar to the Worksheet Editor but with Input Parameters and Output Unit up front.

Primary user: Estimator · Lead Estimator.

Key content:

  • Metadata panel: name (unique workspace-wide), description, Output Unit, Categorization tags, notes
  • Input Parameters pane: ≥1 required — name · unit · default value · description
  • Worksheet-like editor: Variables, Calculation Blocks, Worksheet Resources, Content Blocks (same structure as the Worksheet Editor, but Variables can have Input Parameter origin)

Key interactions:

  • Declare Input Parameters (promote to Variable references inside the Worksheet)
  • Add Worksheet Resources, Calculation Blocks, Content Blocks (same patterns as Worksheet Editor)
  • Promote Item → Recipe — creates a Recipe whose Worksheet mirrors the source Item

Cross-cutting

15. Anomaly Dashboard ⭐ prototype

Purpose: aggregated view of all Anomaly Review flags across the Estimate, grouped by layer.

Primary user: Estimator · Lead Estimator.

Key content:

  • Summary cards: per-layer counts — Layer 1 (deterministic), Layer 2 (Reference Rate), Layer 3 (historical AI at Release)
  • Flag list: filterable — layer · severity · Item / Resource · description · detected date
  • Layer 1 examples: missing Unit on Resource, Plant without operator, snapshot divergence post-adjudication, Production Rate mismatch, required Code missing
  • Layer 2: Reference Rate out-of-range flags with deterministic explanation
  • Layer 3: AI-assisted anomalies with plain-English rationale (Release)
  • Per-flag actions: resolve / dismiss / jump to source

Key interactions:

  • Filter and sort
  • Jump to source view (Estimate Editor at the affected Item, Worksheet Editor at the affected Worksheet Resource, etc.)
  • Resolve / dismiss — with audit trail
  • Bulk dismiss within a category

See sub-flows/anomaly-review.md.


28. Audit / Activity log

Purpose: read-only feed of write actions with user, entity, timestamp.

Primary user: Admin.

Key content: filterable log of actions listed in foundation/nfr.md §2 (Commercials Rule edits, Submit, Publish, Adjudication lock / re-open, Code edits, Role changes).

Key interactions: filter by user, entity type, entity ID, date range; export CSV.


Admin (views 18 – 27)

All admin views share a common list-and-form pattern — table of entries, create / edit modal, archive. Prototyping is low-fi; spec captures structure, not visual treatment.

Per-view key details:

#ViewGated toSpecific notes
18Users & RolesAdminM365 sync trigger, role assignment (one Role per User)
19UnitsLead Estimator · AdminAdmin-managed library; built-in vs custom flag
20CategorizationsLead Estimator · AdminScope per Categorization (Items / Resources / Tenders / Estimates / combination); options with optional colour; soft-delete
21Flag CatalogLead Estimator · AdminEntries carry scope per Resource Type, value_type (boolean / enum), allowed_options
22Modifier CatalogLead Estimator · AdminEntries carry math_operation, value_unit, default_value, scope per Resource Type
23CodesAdmin onlyCodes are required classifiers on Items / Resources only; sync config — one-time + on-demand manual refresh
24Reference RatesLead Estimator · AdminManual benchmarks; point-rate + tolerance or range; optional Categorization Option scope; not versioned
25Content Block DefinitionsAdminName + explainer; four ship by default (Inclusions, Exclusions, Task Breakdown, Risks)
26BrandingLead Estimator · AdminPublisher output styling
27IntegrationsAdmin onlyXero, M365, MS Project, Workbench — source-of-truth direction, credentials, manual sync triggers

Views explicitly out of scope for v1

Called out so they don’t sneak into the prototype list:

  • Variation management post-award
  • Construction Budget / CTC / FFC views
  • Director Dashboard
  • AI natural-language query surface (Release)
  • Mobile-first views (responsive layouts where practical, but not a dedicated mobile app)