oxFlow Glossary

Shared vocabulary for the oxFlow estimating platform. Terms are grouped by concept.

This glossary is the single source of truth for terminology. Before introducing a new term anywhere (spec, prototype, code), check here first. If the term isn’t here, add it.

Status legend used throughout:

• 🟢 Confirmed — terminology and definition are locked
• 🟡 Working — definition is current but may refine as thinking matures
• 🔴 Open — needs Oxcon input or further thinking before locking

---

1. The core analogy

oxFlow’s estimating model borrows from cooking:

• Ingredients → Resources (labour, materials, plant, subcontract)
• Recipes → reusable combinations of ingredients with instructions
• The cake → Items, the things that get sold to the client

This analogy is deliberate and should carry through UI language wherever useful.

---

2. Top-level hierarchy

The system is organised as a nested hierarchy:

Tender
  └─ Estimate
       └─ Heading (up to 5 levels)
            └─ Item (up to 5 levels)
                 └─ Worksheet (optional)
                      └─ Resources + Recipes + Variables + Content

Every term below sits somewhere in or around this hierarchy.

---

3. Containers

Tender 🟢

A pricing opportunity, typically triggered by a client issuing an RFT or RFP. A Tender is the outermost container in oxFlow. It holds one or more Estimates, plus metadata (client, location, due date, win probability, status).

Related: Estimate, Company, Tender Program

Tender Program 🟡

An MS Project file uploaded at the Tender level. Tasks within the Program can be linked to Items in any Estimate under that Tender. Linking a task to an Item adds a Variable on that Item for the task’s duration, available to Worksheet calculations.

🔴 Open: confirm Tender-level (not Estimate-level) with Oxcon.

Estimate 🟢

A build-up of costs and the container for a submission inside a Tender. A Tender can have multiple Estimates (e.g., different strategies, base vs alternative). An Estimate has a Lead Estimator, status, and ID. Contains Headings and Items.

Related: Tender, Item, Heading, Lead Estimator

Heading 🟡

A structural grouping element inside an Estimate. Headings can nest up to 5 levels deep (heading → subheading → sub-subheading …). Used for organising Items into client-schedule structure. A Heading has no cost of its own — cost rolls up from the Items beneath it.

Related: Estimate, Item, Text Block

Text Block 🟡

A non-cost, non-structural text element that appears in the Estimate tree. Used when a client schedule includes pure narrative that must appear in the submission but isn’t a Heading or Item. 🔴 Open: is Text a distinct type or a flavour of Heading?

Schedule 🟡

Two meanings — disambiguate by context:

1. Client Schedule — the list of items the client wants priced (the “Schedule of Prices” in the tender docs). Imported into an Estimate.
2. Submission Schedule — the list oxFlow produces and submits back to the client.

---

4. Items

The heart of oxFlow’s model — what the client buys. Sections 4–7 (Items, Resources, Recipes, Worksheets) are the core building blocks; understanding the differences is critical.

Item 🟢

The heart of the system — what the client buys. An Item has a description, code, Unit, rate, and quantity. Items can nest (sub-Items up to 5 levels). Items can optionally have a Worksheet attached.

Every Item has an Item Type, a Categorization, a Status (one of Unpriced / Plugged / Priced / Reviewed / Locked — see Status below), optional Item Flags (e.g., Indirect Cost), and optionally an assigned Estimator.

An Item can also carry a plug_rate — a rate entered directly at Item level without a Worksheet build-up. When set and the Worksheet has no cost-contributing children, the Item’s status is Plugged (distinct from Resource-level Plug Rate flag; see §5).

Analogy: the cake.

Related: Item Type, Item Flag, Item Status, Worksheet, Resource, Recipe, Unit, Sub-Item

Item Types

Item Type changes how an Item behaves in the system (appears in submission, carries provisional treatment, etc.). Item Flag is a boolean/enum attribute that adds precision without redefining the Item’s core behaviour.

Schedule Item 🟢

An Item that appears in the client-facing schedule/submission. A Schedule Item must sit at the highest level of its branch — you cannot have a Schedule Item nested under another Schedule Item. Use Headings for structure between Schedule Items.

Normal Item 🟡

An Item used for internal cost build-up but not shown to the client. Contributes to the cost of a parent Schedule Item.

Provisional Item / Provisional Sum 🟡

An Item whose cost is provisional — known to be an estimate only, carries a specific commercial treatment, flagged for review. Only applicable as a Schedule Item.

Rate-Only Item 🟡

An Item quoted as a unit rate with no committed quantity — e.g., schedule of rates work. Only applicable as a Schedule Item.

Excluded / Included Elsewhere 🟡

Status flags on a Schedule Item indicating whether it’s out of scope, or covered by another Item.

Risk Item 🟡

An Item carrying a risk or contingency allowance that’s tracked as a discrete line for reporting. Valued like any other Item. Treated as an Indirect Cost by default (the structural rule still applies; the Type is semantic/reporting). Surfaced separately by Anomaly Review and portfolio reporting.

Note: functionally similar to a Normal Item with the Indirect Cost flag set — the distinct Type exists for reporting clarity.

Item Flags

Indirect Cost 🟡

A flag on an Item marking it as an indirect cost (overhead, preliminaries, supervision, etc.). By default, indirect-vs-direct is derived structurally: any Item that is not a Schedule Item and is not nested under one is treated as indirect. The Indirect Cost flag is an explicit override for cases where an Item structurally sits under a Schedule Item but needs to be treated as indirect for commercials/reporting purposes.

🔴 Open for Oxcon: what is the precise definition of an indirect cost in Oxcon’s world? Examples welcome.

Related: Schedule Item, Commercials, Rule

Inactive 🟢

A flag on a Normal Item that soft-disables it: the Item stays in the tree for history and easy reactivation, but it contributes $0 to cost roll-ups and is rendered distinctly in the UI (greyed / struck-through). Schedule Items use Excluded or Included Elsewhere for the equivalent client-facing semantic.

Related: Item Flags, Excluded

Item Status 🟡

The lifecycle state of an Item. Five states:

Status	Meaning
Unpriced	No pricing information — empty Worksheet (no cost-contributing children) and no plug_rate
Plugged	plug_rate entered directly at Item level; Worksheet has no cost-contributing children
Priced	Rate derived from Worksheet build-up (≥1 Worksheet Resource / Recipe / sub-Item contributes cost)
Reviewed	Priced + senior review complete
Locked	Parent Estimate has been Submitted; no edits allowed

Unpriced / Plugged / Priced are derived automatically from Worksheet content + plug_rate presence. Reviewed and Locked are manual / cascaded states built on top.

Submission block: an Estimate cannot be Submitted if any Item is in Unpriced or Plugged state. Estimators can navigate to the Publisher preview, but the Submit action is blocked with a clear anomaly list.

Note on Plugged vs Plug Rate — Plugged is an Item-level status (a direct rate entry with no build-up). Plug Rate is a separate Resource-level flag (see §5) marking a placeholder rate in a Price Book. A Priced Item’s Worksheet can contain Plug Rate Resources — the Item is still Priced (the Plug Rate inside is flagged in Anomaly Review separately).

Related: Item, plug_rate, Plug Rate (Resource flag), Anomaly Review

---

5. Resources

Resource 🟡

The atom-level building block. A Resource has a description, rate, and Unit. Everything in oxFlow’s cost build-up ultimately decomposes into Resources.

Resources are organised into Price Books, typed (Labour, Material, Plant, Subcontract, Other), and carry Flags that describe their scope and conditions.

Analogy: the ingredient.

Related: Price Book, Resource Type, Flag, Unit, Recipe

Resource Type 🟢

Governs how a Resource behaves in the system. Resource Types are fixed — users cannot add new types. Flex happens through Categorization.

Known types:

• Labour
• Material
• Plant
• Subcontract
• Other (catch-all; no Flags, no type-specific Anomaly checks)

What Type actually governs (narrow and deliberate):

1. Which Flag set is available for the Resource
2. Whether the Resource can be an output of Subcontract Package Adjudication (Subcontract only; all others reach the Estimate via Price Book Adjudication or direct entry)
3. Which type-specific Anomaly checks apply (e.g., “Plant without operator”, “Material without cartage allocation”)

Structurally, all Resource Types share the same data model (description, Unit, rate, Categorization, Flags). There is no special data-model treatment for Subcontract or Other — they are Resource Types with their own Flag/Anomaly configuration.

Flag 🟢

A descriptive, boolean or small-enum attribute drawn from an admin-curated Flag Catalog. Flags add domain precision to Resources without changing cost math. Each Flag declares a scope (applies to All Resource Types, one specific type, or multiple types). Resources pick applicable Flags during create/edit; the catalog is filtered by Resource Type to show only relevant options.

Scope semantics: a flag’s scope is set by admin. E.g., “Wet hire” might scope to Plant only; “Region-specific” might apply to Labour, Material, and Plant.

Plug Rate as a Flag: Plug Rate is a specific Flag in the Flag Catalog, scope = All Resource Types, boolean. It marks a Resource as a placeholder rate. Distinct from Item Status = Plugged (see §4).

Illustrative examples per Resource Type:

• Labour: Public holiday / standard / weekend rate; Region-specific; Includes / excludes small tools; 8-/9-/10-hour day
• Material: Includes / excludes cartage; Includes / excludes freight; Supply-only / supply + install
• Plant: Wet / dry hire; Internal / external plant; Fuel included / separate; Daily / weekly / monthly rate
• Subcontract: Fixed price / rates-only; Includes / excludes insurance; Design + construct / construct-only

The full Flag Catalog is admin-managed; the resource entity spec documents scope rules and all available flags.

Related: Flag Catalog, Modifier, Resource, Worksheet Resource

Plug Rate 🟢

A specific Flag in the Flag Catalog, scope = All Resource Types, boolean. Marks a Resource as a placeholder rate (real pricing not yet confirmed). Used inside a Worksheet, a Plug Rate Resource is flagged by Anomaly Review.

Distinct from Item Status = Plugged. See the Item Status entry above for the distinction:

• Plugged (Item status): the Item’s rate was entered directly at Item level (no Worksheet build-up)
• Plug Rate (Resource flag): a Resource marked as placeholder; can live inside a Priced Item’s Worksheet

A single Item can be Priced (build-up present) AND contain Plug Rate Resources. The two concepts trigger different Anomaly Review flags.

Related: Flag, Flag Catalog, Item Status, Resource

Modifier 🟢

A numeric attribute drawn from an admin-curated Modifier Catalog that adjusts cost mathematics. Each Modifier has:

• A scope (applies to All Resource Types, one specific type, or multiple types)
• A math operation (one of: quantity_multiplier, rate_adder, lump_sum_add, total_multiplier)
• A value unit (e.g., %, $/unit, lump $)
• A default value (optional; Resources can carry defaults; Worksheet Resources inherit and allow per-instance override)

Math application order: when a Modifier applies, operations flow in sequence: quantity → rate → lump-sum-add → total-multiplier.

Values flow through: when a Resource declares Modifier defaults, those values carry through to Worksheet Resources as snapshots; estimators can override per instance. Overrides do not feed back to the base Resource.

Illustrative examples:

• Wastage (quantity_multiplier, %, scope: Material)
• Cartage per unit (rate_adder, $/unit, scope: Material)
• Weekend penalty (total_multiplier, %, scope: Labour)
• Mobilisation fee (lump_sum_add, lump $, scope: Labour, Subcontract)

Modifier Catalog is admin-managed and integrated with Resource and Worksheet Resource snapshot semantics (see BR-040).

Related: Flag, Flag Catalog, Resource, Worksheet Resource, Snapshot

---

6. Recipes

Recipe 🟢

A reusable, named combination of Resources — with its own Worksheet, logic, at least one Input Parameter, and a declared Output Unit. Recipes live in a shared Recipe Library and can be dropped into any Item’s Worksheet.

Output Unit: the Unit the Recipe’s result is expressed in (e.g., day, pump, m³). The Recipe’s Worksheet evaluates to a rate per Output Unit; the host Worksheet multiplies by a quantity.

Example: a “Concrete Pump” Recipe with Input Parameters Concrete Quantity and Number of Trips, and Output Unit day. The Recipe computes a $/day rate; the Item using it supplies a number of days.

Analogy: the recipe.

Related: Resource, Worksheet, Input Parameter, Output Unit, Recipe Library, Recipe Builder

Input Parameter 🟢

A named variable defined at the top of a Recipe (and required — every Recipe must have at least one). Input Parameters drive the Recipe’s internal calculation; they’re not how the host Worksheet measures quantity (that’s the Output Unit).

Example: a “Concrete Pump” Recipe has Input Parameters Concrete Quantity and Number of Trips.

Output Unit 🟢

The Unit a Recipe’s result is expressed in when used in an Item’s Worksheet. Declared on the Recipe definition. The Recipe’s Worksheet calculation produces a rate per Output Unit; the host Item supplies a quantity in that Unit and the contribution = rate × quantity.

Example: the “Concrete Pump” Recipe has Output Unit day. Its Worksheet evaluates to a $/day rate; the Item using it supplies a number of days.

See BR-030 (Recipes require an Output Unit).

Production Rate 🟡

A rate expressing how quickly work is performed — units of output per unit of time (e.g., 100 m³/day, 25 m/hr, 30 doors/shift). Production Rates link quantity to duration: given any two of (quantity, duration, production rate), the third is derivable.

Where they appear in oxFlow:

• Manually declared inside a Worksheet as a Variable (e.g., pour_rate = 25 m³/hr) — same mechanism as any other Variable
• Derived when an Item is linked to a Program Task — production_rate = item_quantity ÷ task_duration
• Used by Anomaly Review — cross-checked for consistency when both declared and derived values exist

Production Rate is not a separate entity — it’s a Variable pattern with semantic meaning.

Related: Variable, Unit, Program Task, Anomaly Review

---

7. Worksheets

Worksheet 🟢

The methodology surface. A canvas attached to an Item or a Recipe where the estimator explains the logic, calculates quantities, defines variables, and assembles resources. Every Item has exactly one Worksheet — simple Items just have sparse content (UI adapts).

A Worksheet can contain:

• Text blocks and headings
• Variables and Input Parameters
• Calculation blocks
• Embedded PDFs, images, Excel spreadsheets
• Resources (added on the fly or dragged from Price Books)
• Recipes (dragged from the Recipe Library)
• Production rates
• Structured content blocks (inclusions, exclusions, task breakdown, risk breakdown)
• Linked Tender Program tasks (which expose task duration as a Variable)

Worksheets are both the build-up mechanism and the audit trail — they explain how the number was reached, not just what the number is.

Related: Item, Recipe, Variable, Input Parameter, Resource

Worksheet Resource 🟡

A usage record linking a Resource into a specific Worksheet. Stores a snapshot of the rate, quantity, and wastage at time of drag-in — the Worksheet Resource does not auto-update when the underlying Resource changes. Snapshot semantics extend to modifier values: when a Resource carries Modifier defaults, those values are also snapshotted; per-instance overrides are allowed on the Worksheet Resource. Divergence between the snapshot and the live Price Book is flagged by Anomaly Review.

Rate-edit mechanics: three mechanisms exist for adjusting a Worksheet Resource’s effective rate: per-instance override (default — BR-047), bulk “Apply to this Estimate” (BR-048), and fork to a new Resource in the Estimate’s Project-Specific Price Book (BR-049). Any rate change cascades affected parent Items from Reviewed back to Priced (BR-049a).

Analogy: if Resource is a menu item, Worksheet Resource is a line on your order.

Related: Resource, Worksheet, Modifier, Snapshot

Worksheet Recipe 🟡

A usage record linking a Recipe into a specific Worksheet, with snapshotted input parameter values. Same snapshot semantics as Worksheet Resource — does not auto-sync with the underlying Recipe; divergence is flagged by Anomaly Review.

Variable 🟡

A named value inside a Worksheet that can be referenced in calculations. A Variable can originate from:

• Manual definition in the Worksheet
• Input Parameters (if inside a Recipe)
• A linked Tender Program task (exposes task duration)
• Another calculation

The origin is tracked internally but not surfaced as a separate concept — to the estimator, it’s just a Variable.

Calculation Block 🟡

A section of a Worksheet that computes a value from Variables and other inputs. Produces numbers that can feed Resource quantities.

Content Blocks 🟢

Structured slots inside a Worksheet for semi-structured data. Four ship by default:

• Inclusions
• Exclusions
• Task Breakdown
• Risks

Admins can define additional Content Blocks. Each block has:

• A Name (used as the label in the Worksheet)
• An Explainer (guidance text shown to the estimator when the block is opened, describing what belongs in it)

Content Blocks are text-with-a-label, but having standard labels lets us aggregate and report on them across items and estimates.

Build-up 🟢

The composed cost of an Item, derived from its Resources, Recipes, and sub-Items. The build-up is what the Worksheet produces.

---

8. Pricing & procurement

Price Book 🟢

A named collection of Resources, typically tied to a supplier. Used as the source of prices during estimate build-up.

Every Price Book has a Price Book Type, a scope (date range, region, tender link if project-specific), and a source type:

• user-created — manually curated by an admin or estimator
• system-generated — automatically created by a Subcontract Package Adjudication on award; hidden from the default Price Book list, read-only via the Price Book UI (see Adjudication)

Scope behaviour: Resources inherit the Price Book’s scope. No per-Resource scope override in v1. Price Books auto-archive when scope_end_date < today (logical check at query time) — archived Price Books are read-only; existing Worksheet Resources retain their snapshot references.

Multiple Price Books per Supplier for the same date range are allowed (e.g., different product categories). Names must be unique workspace-wide.

“Project-Specific” scope refers to a Tender (industry-standard label; the term “Project” is used loosely for readability — technically the scope is a Tender).

Related: Resource, Price Book Type, Supplier, Adjudication

Price Book Type 🟡

• Project-Specific — attached to a single project; no supplier required
• Internal — in-house reference rates; no supplier required
• External — tied to a supplier (supplier required)

Supplier 🟡

A Company with the Supplier Company Role. Suppliers can be attached to External Price Books.

Subcontract Package 🟡

A named bundle of Items selected from the Estimate to be priced as a package by subcontractors. Persists beyond adjudication and can be re-opened.

Note: There is no separate “Subcontract Resource” concept. The output of a Subcontract Package adjudication is a system-generated Price Book containing Resources of Type Subcontract; each Item in the Package references one of those Resources.

Adjudication 🟢

The process (and the object recording it) of comparing multiple suppliers’ prices and selecting a winner. Adjudications are persistent — they live with the Estimate, can be re-opened, and the Estimate reflects the latest committed state.

Shared six-step workflow (applies to both Adjudication flavours):

1. Generate — assemble the comparison package (a list of Resources for Price Book Adjudication, or a bundle of Items for Subcontract Package Adjudication)
2. Export/Send — export the package as Excel/PDF to send to competing suppliers or subcontractors
3. Import — import the priced returns back into the Adjudication
4. Compare — side-by-side view across competing returns, with +/- variances applied for inclusions/exclusions
5. Normalise — add missed items to competing returns for like-for-like comparison (transient to the Adjudication, not written back)
6. Transfer to buildup — the selected winner’s pricing is applied to the Estimate (replacement for Price Book Adjudication; system-generated Price Book for Subcontract Package Adjudication)

Two distinct flavours, differing in what they scope over:

Price Book Adjudication 🟡

Scopes over Resources selected from across the Estimate. The estimator picks a set of Resources (can be any type — materials, labour rates, plant rates), imports competing prices from multiple Suppliers, and on award the winning rates replace the existing Resources in the Estimate.

Subcontract Package Adjudication 🟡

Scopes over a Subcontract Package (a named bundle of Items selected for subcontract pricing). The estimator imports competing prices from Subcontractors, and on award the winning price is written into a system-generated Price Book as Resources of Type Subcontract — one per Item in the Package. Each Item’s Worksheet gets a Worksheet Resource referencing one of those Resources.

A Subcontract Package is a persistent object — it can be re-adjudicated if scope changes or new prices come in; the same system-generated Price Book is updated in place.

Re-open constraint: an Adjudication (either flavour) can be re-opened only while the parent Estimate is in an editable state. Once the Estimate transitions to Submitted (or cascaded Won / Lost / Archived), its Adjudications are frozen.

Price Book Adjudication now also supports multiple rounds (previously one-shot) — consistency with Subcontract Package Adjudication. Re-awarding produces a new round.

Import Wizard 🟡

A shared UX pattern for importing Excel files into oxFlow. Used at two points in v1:

• Client Schedule import at Tender / Estimate creation (parses the client’s BOQ spreadsheet)
• Adjudication return import (priced returns from Suppliers or Subcontractors — BR-068b)

The wizard provides smart column-mapping (auto-detect common column names like Item No, Description, Qty, Unit, Rate), preview validation (warnings for missing quantities, unrecognised units, duplicate item numbers), and manual field override.

Variance notes during Adjudication are captured as Content Block instances on the affected Items’ Worksheets — not on the Adjudication itself. They persist after award as line-level context.

Related: Price Book, Subcontract Package, Resource, Item

---

9. Commercials & submission

Anomaly Review / Anomaly Dashboard 🟡

A pre-Commercials review screen that surfaces likely errors before the estimate progresses. Organised in three layers, each shipping at a different milestone:

Layer 1 — Deterministic rule checks (Alpha):

• Items with plant but no fuel / no operator allocated
• Materials with unusually high wastage / missing transport or cartage allocation
• Items flagged as Provisional Sums or missing quantities
• Item is Unpriced (no Worksheet build-up and no plug_rate — blocks submission)
• Item is Plugged (direct plug_rate with no build-up — blocks submission)
• Worksheet contains Plug Rate Resources (separate from Plugged status; surfaced for resolution but doesn’t block submission)
• Unit mismatch between Item quantity Unit and Resource rate Unit
• Snapshot divergence — Worksheet Resource rate differs from current Price Book rate
• Recipe snapshot divergence — Worksheet Recipe differs from the underlying Recipe definition
• Missing required Code values
• Production Rate inconsistency — declared Production Rate conflicts with duration/quantity derived from a linked Program Task
• Risk Items unidentified or missing valuation
• Missing modifier defaults where Resource Type typically requires them (admin-configurable per Modifier)
• Modifier override beyond reasonable range (optional; admin-configured threshold, if enabled)
• Bulk override inconsistency — Worksheet Resources in the same Estimate using the same Resource at different rates (e.g., after a bulk override but a new drag-in uses the Price Book rate)

Layer 2 — Reference Rate checks (Alpha rules-first, Release AI-assisted):

• Item unit rate outside the matching Reference Rate’s expected range (rules-first — see Reference Rate definition)
• AI semantic match where Reference Rate tagging is missing (Release milestone)

Layer 3 — Historical comparison (Release, AI-driven):

• AI compares the current estimate against similar completed projects, flagging items that look under/over-priced relative to Oxcon’s own historical data
• AI explains why each anomaly was flagged, cross-referencing rates, similar past items, and estimate context

Each flag has a severity indication, a source (Layer 1/2/3), and — where provided by AI — a plain-English explanation and suggested action. Estimators can accept or dismiss flags; dismissal data feeds back into AI matching over time.

🔴 Open: full list of Layer 1 checks for launch.

Reference Rate 🟡

An admin-defined expected unit rate for a specific type of work, used by Anomaly Review as the anchor layer for flagging estimating outliers. Not used in cost build-up.

No versioning: a single current value per Reference Rate. Edits overwrite the previous value. Anomaly Review Layer 3 (AI historical comparison) is a separate mechanism — it uses archived Price Books and completed estimates, not Reference Rate history.

Examples:

• Reinforced concrete works: $450–550/m³
• Bored piles: $650–850/lm
• Concrete deck pour: $380–450/m²

Attributes: name, Unit, expected rate (point value with tolerance, or min/max range), optional Categorization Option scope, description/notes.

How they’re used in Anomaly Review:

• Rules-first match (Alpha): an Item is compared to a Reference Rate when its Unit matches and (if the Reference Rate has a Categorization scope) the Item carries that Categorization Option. Outside-range rates flagged directly.
• AI-assist match (Release): when an Item isn’t tagged or doesn’t match any Reference Rate directly, the Anomaly Review’s AI layer semantically matches the Item’s description to candidate Reference Rates and flags probable mismatches with a confidence score.

Related: Anomaly Review, Unit, Categorization

Commercials 🟢

The rules layer applied after the build-up is complete. Commercials turns cost into revenue by applying a sequenced set of rules (markup, margin, contingency, indirect costs, etc.).

Related: Rule, Submission Value

Rule 🟡

A single commercial adjustment. Has a name, a type (percentage / lump sum / rate adjustment), and a scope. Rules apply in order — sequence matters because later rules can stack on earlier ones.

Rule scope can target:

• All Items
• Direct-cost Items only (structurally derived, unless overridden by the Indirect Cost flag)
• Indirect-cost Items only
• A specific Categorization value
• A specific Item Type
• 🔴 Open: full list of rule-scope targets

Markup / Margin / Profit / Contingency 🟡

Common rule names. oxFlow treats them all as Rules — the label is user-defined, the behaviour is governed by the rule’s type and scope.

Submission Value 🟢

The final rate or lump sum shown to the client for a Schedule Item. After Commercials run, the estimator gets one last editable pass on the Submission Values before publishing.

Publisher 🟢

The final step before delivering the estimate. The Publisher view handles:

• Cover letter
• Conditions
• Inclusions / exclusions
• Branding
• The output schedule

Produces the submittable artifact (PDF, Excel, etc.).

---

10. Admin

10.1 People & access

User 🟢

A person with access to oxFlow. Users sync from Microsoft 365. Access is controlled by assigning a Role.

Role 🟢

One of three:

• Admin — full access including the Admin page and licensing
• Lead Estimator — can create and configure Tenders and Estimates; can do everything an Estimator can
• Estimator — can build up and edit Items, Resources, Recipes, Worksheets within Estimates

Full capability matrix lives in roles-permissions.md.

Company 🟢

An external organisation — client, supplier, subcontractor, or any combination. Companies sync from Xero; they are not created directly in oxFlow.

Each Company has one or more Company Roles that govern where it can be assigned.

Company Role 🟢

A multi-select attribute on a Company. A single Company can carry any combination of the three Roles (a supplier may also be a subcontractor, for example).

Roles and their assignment scope:

• Client → assignable to a Tender
• Supplier → assignable to an External Price Book
• Subcontractor → assignable to a Subcontract Package

Defaulting behaviour: Company Roles are initialised from Xero metadata on sync where possible (e.g., a Xero customer → Client; a Xero supplier → Supplier). Where Xero is ambiguous, the default is Supplier. The Role set is editable in oxFlow after sync.

Real-time collaboration 🟡

Multiple Users can work on the same Estimate concurrently. Explicit locking model: while a User is actively editing an Item (and its Worksheet), that Item shows as “currently edited by [User]” to others — read-only for them. Locks release on close or after an idle timeout. Across different Items, multiple Users can work simultaneously.

🔴 Open for Oxcon discussion: the proposal calls for “real-time collaboration” — this interpretation (explicit per-Item locking) is safer and simpler than Google-Docs-style concurrent field editing. Confirm the model with Oxcon before Alpha build.

Related: User, Estimate, Item

10.2 Integrations

Xero 🟢

Source of truth for Companies. Companies are synced in; not edited in oxFlow. Xero metadata seeds initial Company Roles.

Microsoft 365 🟢

Source of truth for Users. Users are pulled in; Roles are assigned inside oxFlow.

MS Project 🟡

Source format for the Tender Program upload. Tasks become linkable duration Variables on Items.

Workbench 🟡

The downstream cost management system used by Oxcon for project delivery. When an Estimate’s parent Tender is Won, the Estimate is promoted into a project and exported to Workbench. Codes (Activity Code on Resources, Workcentre on Items) populate Workbench’s hierarchy. Sync direction is primarily oxFlow → Workbench at promotion; Workbench → oxFlow for Code library sync.

10.3 Classification & measurement

Unit 🟢

A measurement in which an Item’s quantity or a Resource’s rate is expressed.

Examples: m, m², m³, ea (each), no (number), hr, day, wk, kg, t (tonne), LS (lump sum).

Units are drawn from a managed library that admins can extend. Lump sum (LS) is a valid Unit for any Resource or Item that isn’t quantity-driven.

Unit conversions (v1): oxFlow does not auto-convert between units. When an Item’s Unit differs from a Resource’s Unit, the estimator performs the conversion explicitly inside the Worksheet (as a Variable or Calculation Block). This is tracked in the Anomaly Dashboard so unit mismatches are flagged for review before Commercials. Auto-conversion may come in a later version.

Categorization 🟢

A user-defined, flexible tagging system. Categorization is for reporting only — it never changes system behaviour (that’s what Type is for) and is optional (that’s what distinguishes it from a Code).

A Categorization has:

• A name
• A set of options (the allowed values)
• A scope — does it apply to Items, Resources, Tenders, Estimates, or a combination?

Lifecycle: soft-delete (archive) rather than hard-delete. Archived Categorizations remain visible on historical entities that used them but are not available for new selections. Can be un-archived.

Inheritance: sub-Items inherit their parent Item’s Categorization Options at creation time. Estimator can override per sub-Item. Changes to the parent after the sub-Item is created do NOT retroactively propagate.

Colour palette: Options can carry either a predefined-palette colour OR a free-form hex code.

Bulk tagging: supported — users can select multiple Items/Resources and apply the same Categorization Option in one action.

Related: Type, Flag, Code

Code 🟡

A required, admin-defined classifier on an entity, intended primarily for integration with downstream cost-management systems. A Code shares the same structure as a Categorization (name, scope, options) but with two key differences:

• Required — a Code value must be set on every instance of the scoped entity. Missing Codes block downstream export (tiered enforcement — see BR-127).
• Integration-linked — a Code’s options can be sourced/synced from an external system (e.g., Workbench).

Scope restriction: Codes apply only to Items and Resources. No Code scoped to Tenders or Estimates in v1 (Categorization handles those).

Creation authority: Admin-only — Lead Estimators cannot create Codes, only use existing ones. See roles-permissions.md.

Sync: one-time initial migration + on-demand manual refresh (no scheduled sync cadence).

Examples:

• Activity Code — required on every Resource for Workbench integration
• Workcentre — required on every Item for Workbench integration

Note on Item code attribute: Item also has a free-text code attribute (sometimes called “schedule code”) for client-facing identification — this is separate from the Code concept defined here. Item’s schedule code is an informal label; Codes (BR-125) are structured classifiers.

Related: Categorization, Anomaly Review, Integrations. Detailed rules: BR-125–128. Permissions: roles-permissions.md §3.

Type 🟢

A structural attribute that governs how an entity behaves. Contrast with Categorization (reporting only) and Flag (adds detail but rarely changes behaviour).

• Item Type → determines if an Item appears in the submission schedule, is provisional, etc.
• Resource Type → determines what flags apply, how it’s handled in adjudication
• Price Book Type → determines whether supplier is required

Flag 🟢

A boolean or small-enum attribute that adds domain precision without fundamentally changing how an entity behaves. Flags are entity-specific:

• Resource Flags → e.g., “Includes cartage”, “Wet hire” (see §5)
• Item Flags → e.g., “Indirect Cost” (see §4)
• Company Roles → a set of flags on Company (see §10.1)

The exact Flag set per entity is defined in that entity’s spec (Batch B).