Honest assessment of what Batch A (glossary, domain model, business rules, roles & permissions) has missed or weakened when compared to:
- The Oxflow Phase 1 Proposal (Feb 2026) — the committed Phase 1 scope (126 functions across Alpha/Beta/Release milestones)
- The 2022 Assessment of Estimating and PCM Solutions — the original discovery that led to picking Benchmark + Workbench
- The 2023 Proposed Functionality Matrix (REV1) — 280+ user stories across 12 user-profile × workflow sheets
No changes made to Batch A yet — this is for your review.
Executive summary
Magnitude of gap: Batch A covers roughly 70% of the Alpha milestone (Estimating). It barely touches the Beta milestone (Forecasting — Construction Budget, Variations, CTC/FFC, MS Project linking, Director Dashboard) and is completely silent on the Release milestone (Cash Flow, Progress Claim Forecasting, Reporting Suite, AI layer, NFRs, Benchmark decommissioning).
Three classes of gap:
- Scope/phasing not reflected — no mention that the product ships in three milestones with different surface areas. Batch A reads like it’s one all-or-nothing platform.
- Missing domain concepts — ~10 first-class concepts committed in the proposal that have no representation in Batch A (Construction Budget, Variation, Revision, CTC/FFC, Module, Production Rate, Composite Item, AI queries, and more).
- Adjacent context missing — NFRs, migration, Benchmark retirement, Phase 2 roadmap, performance and security expectations.
The proposal is not aspirational — it’s what we’ve committed to deliver by Jun 15, 2026. Batch A needs to account for all of it, even if some entities are tagged “Beta only” or “Release only” and detailed later.
1. Phasing / scope structure — not in Batch A at all
The proposal splits Phase 1 into three milestones:
| Milestone | Dates | Function count | What Oxcon gets |
|---|---|---|---|
| Alpha — Estimating | Feb 16 → Apr 13 (8 wks) | 68 | Replace Benchmark UI |
| Beta — Forecasting | Apr 14 → May 18 (5 wks) | 34 | Workbench integration, Construction Budget, Variations, CTC |
| Release — Go-Live | May 19 → Jun 15 (4 wks) | 24 | Cash flow, progress claims, reporting, AI, training, Benchmark decommission |
Missing from Batch A:
- No milestone or phase tag on any entity, rule, or capability
- No explicit map of which concepts belong to which milestone
- Dev team reading Batch A wouldn’t know that e.g. Variations are committed for Beta, not “someday”
Recommendation: add a phase tag (Alpha / Beta / Release / Phase 2) to every entity in the domain model and every rule in the business rules catalogue. This gives the team a sequencing signal without fragmenting the docs.
2. Missing entities & concepts (critical)
These are first-class concepts in the proposal (all Phase 1 committed scope) that do not exist in Batch A.
2.1 Construction Budget (Beta)
Proposal section B2. The Estimate, once imported into Oxflow as the construction budget, becomes a different object with different state, revision history, and editing rules (post-tender adjustments, quantity updates for M&V contracts, error checking at budget level). Our Batch A Estimate model stops at submission and has a one-line “moves to project” cascade. We need a Construction Budget entity distinct from Estimate.
2.2 Variation (Beta)
Proposal section B3 — 8 MUST functions. Variations have:
- Their own schedule of values (B3.1)
- Their own cost buildup, reusing estimating tools — resource library, recipes, formulas (B3.2)
- A state machine: Draft → Submitted → Under Review → Approved → Rejected (B3.5)
- Unique reference numbers (B3.7)
- Linkage to schedule items (B3.8)
- Revision history per variation (B3.6)
This is entirely missing from Batch A. A fully modelled entity with its own lifecycle, commercials treatment, and reporting dimension.
2.3 Revision / Period Snapshot (Beta)
Two proposal touchpoints: B2.1 “Adjust cost buildup with revision tracking — save as named revisions” and B4.8 “Period snapshots — save immutable snapshots at end of each reporting period”. Plus B3.6 (per-variation revision history).
Batch A has no Revision concept. “Multiple Estimates per Tender” is as close as we get and it’s not the same thing — Revisions are within an Estimate/Construction Budget, not alongside. Without this concept, there’s no auditable history of budget changes over the life of a project.
2.4 CTC / Forecast Final Cost (Beta)
Proposal section B4 — 8 MUST functions. The Cost-to-Complete + Forecast Final Cost calculation is the single most-rated feature in the historic XLSX (every PM reporting user story is rated MUST). FFC = Actual to Date + Committed + CTC, with comparisons across periods and against both original construction budget and original tender estimate.
Batch A has nothing here. No CTC entity, no FFC derivation, no period-over-period comparison. This is core to Phase 1 Beta.
2.5 Cash Flow Forecasting (Release)
Proposal section C1. Project outgoing payments across the timeline based on budget + programme + payment terms. No equivalent in Batch A.
2.6 Progress Claim Forecasting + M&V support (Release)
Proposal section C2. Revenue claim schedule projection, updating agreed/measured/forecast quantities for measure-and-value contracts, applying % likelihood to contested revenue. Batch A has Submission Value but no progress-claim or M&V concept.
2.7 Reporting Suite (Release)
Proposal section C3 — 5 distinct report types: estimate summary, position report (the core monthly report showing budget vs actual vs FFC), variance report, resource usage report, percentage complete reporting. Batch A has no Report entity at all.
2.8 AI Reporting & Interaction (Release)
Proposal section C4 — 8 functions including:
- Natural language project queries (“What’s the FFC on earthworks?“)
- Auto-generated position report narratives
- Anomaly explanation
- Estimate review assistant (AI peer review against historical projects)
- Variation narrative drafting
- Multi-project portfolio summary
- Conversational data exploration
- Scheduled agentic workflows
Batch A is silent on AI. This is a major architectural concern (how does AI access the data model? what governance?). At minimum Batch A should acknowledge the AI layer as a first-class concept.
2.9 Director Dashboard / Portfolio View (Beta)
Proposal section B6 — 5 functions. Multi-project view with RAG status, monthly position review per project, trends over periods, consolidated business-level totals. Batch A has nothing at portfolio level. The Director/Executive user doesn’t exist as a Role either (see §4).
2.10 Module (Alpha) ⚠️ New concept we missed
Proposal A6.4: “Multiple pricing modules per SOQ line — generate multiple internal pricing modules linked to a single client schedule line item.”
This is a concept we haven’t captured anywhere: one client-facing Schedule Item can have multiple internal pricing modules (different methodologies / crews / approaches that roll up into the same submitted rate). Referenced again in B2.4 “gross profit variance at module level”. Our current Item hierarchy doesn’t capture this cleanly — sub-items partially do it, but “Module” reads as a distinct abstraction worth investigating with Oxcon.
2.11 Production Rate / Productivity linking (Alpha)
Proposal A4.5: “Productivity rate linking — link a quantity to a production rate to auto-calculate durations. E.g., 500m³ earthworks at 100m³/day = 5 days.”
Our Batch A Worksheet definition mentions “production rates” as a bullet but there’s no first-class Production Rate entity. This matters because:
- Links quantity → duration → crew cost (a distinct mechanic from just “rate × quantity”)
- Drives crew sizing decisions
- Feeds into cost-program linking in Beta (B5.2)
2.12 Historical Rate Library (Alpha + AI)
Proposal A5.7 “Library of previous unit rates — access historical unit rates from completed estimates. Compare current pricing against historical data.” Plus A5.8 “Add unit rates to central library — after estimating, save confirmed unit rates back to the central library for future reference.” Plus the AI review assistant (C4.4) explicitly “reviews a completed estimate against historical projects”.
Batch A has Plug Rate but no historical-rate library concept. This is a significant asset being under-modelled — the data that powers the AI review layer.
2.13 Composite Item / Total-Subtotal / Text Heading (Alpha) — Item type miss
Proposal A2.5 lists six Item Types: “Normal (priced), Composite (grouping header), Total/Subtotal, Provisional Sum, Text heading, Rate-only.” A2.6 adds detail: “Composite items — group normal items under a composite header. The composite shows a rolled-up rate; individual items are hidden in the client quote but visible internally.”
Batch A has: Normal, Schedule, Provisional, Rate-Only, Excluded/Included Elsewhere. Missing:
- Composite — groups other Items and shows a rolled-up rate
- Total/Subtotal — calculated row
- Text heading — Batch A has “Text Block” as a separate concept rather than an Item Type, creating inconsistency
2.14 Benchmark Data Migration (Alpha & Release)
Proposal A3.8 “Benchmark rate library migration — migrate all existing Benchmark resources (codes, descriptions, rates, groups, units, categories) into Oxflow. One-time data migration.” Plus C5.5 “Benchmark data migration (final) — complete migration of all active estimates, libraries, and historical data.” Plus C5.6 “Benchmark decommission — full cutover. Benchmark licenses terminated. All users on Oxflow.”
Batch A has no concept of migration, cutover, or legacy-system retirement.
2.15 Workbench bi-directional live integration (Beta)
Proposal B1 — 4 MUST functions: “Connect to Workbench API”, “view actual-cost-to-date per cost code” (live), “view committed-cost-to-date per cost code” (live), “budget transfer from estimate”. Batch A’s Workbench reference is a one-liner under Integrations with no architectural detail — no notion of live reads, no field-level contract, no sync direction.
2.16 Construction Programme (distinct from Tender Programme) (Beta)
Proposal B5 — MS Project XML/MPP import for the construction programme (post-tender), cost-program linking (“associate cost items with programme tasks”), time-based cost distribution (“distribute budgeted costs across the programme timeline”). Batch A only has Tender Program. These are structurally similar but semantically distinct contexts (tender-time vs construction-time), and the time-based cost distribution is a new mechanic.
3. Refinements to existing Batch A concepts
3.1 Item status lifecycle — wrong states
Proposal A9.6 calls out: “Status tracking per schedule item — Not Started / In Progress / Review Ready / Completed.” Batch A has Priced / Reviewed / Locked. Different framing; proposal is closer to estimator language.
3.2 Estimate attributes are thinner than proposal
Proposal A12 specifies estimates should have: “name, quote number, date, estimator, region, client” plus ability to duplicate projects (A12.2) and project-level notes (A12.3) and multi-user project access with real-time collaboration (A12.4). Batch A’s Estimate entity has just name/number/status/notes/Lead Estimator. Missing: quote number, region, duplication flow, and collaboration model.
3.3 Commercials need item-level and spread mechanics
Proposal A7.2: “Margin/risk allocation per item — apply different OH&P margins and risk percentages to individual items, sections, or the whole project.” A7.4: “Spread / submission rate adjustment — distribute markup across items for client submission. Adjust submission rates without changing the underlying cost buildup.”
Batch A’s Rule scopes cover “specific Item” and “all items” but the actual mechanic of distribution (spread across items) vs. targeting (apply to one) is under-specified.
3.4 Subcontract workflow has 6 steps, not just adjudication
Proposal A8 covers the full Subcontractor Management lifecycle:
- A8.1 Generate subcontractor schedule to price
- A8.2 Send schedule to subcontractor (export)
- A8.3 Import priced subcontractor schedule
- A8.4 Compare pricing (adjudication)
- A8.5 Add cost items missed by subcontractors (normalise for like-for-like)
- A8.6 Transfer selected sub quote to buildup
Batch A’s Subcontract Package + Adjudication covers A8.4 but the other 5 are missing or implicit. This is a workflow spec gap more than a data-model gap, but it should inform entity attributes (e.g., Subcontract Package needs “sent date”, “imported date”, “schedule file” attributes).
3.5 Real-time collaboration
A12.4 — “multi-user project access — multiple estimators working on the same project simultaneously. Real-time collaboration.” Batch A has no concurrency/collaboration model. This is a major architectural concern (locking, conflict resolution, operational transformation or CRDT approach, etc.).
3.6 Risk item identification
Proposal B2.5: “Risk item identification and valuation — identify all risk items included in the budget with their values.” Batch A has Commercials rules for contingency but no concept of Risk Items as individual line items with their own valuation and tracking.
3.7 Item copy/duplicate mechanics
Proposal A2.9: “Copy items between sections/projects.” A5.5: “Copy cost buildups between items.” A5.4: “Cost templates (item buildups) — save an entire item buildup as a reusable template, apply to new items in future estimates.”
Batch A has Recipes (for reusable crews) but not this item-level copy-paste and cost-template mechanic. Cost Templates vs Recipes vs Item Templates is a concept cluster that needs explicit definition.
4. Missing user profiles / roles
Batch A has 3 Roles (Admin / Lead Estimator / Estimator). Historic docs specified 5 user profiles and proposal confirms more:
| Profile | Their work in the proposal | In Batch A? | Priority |
|---|---|---|---|
| Estimator | Alpha functions | ✅ | — |
| Lead Estimator | Configure Estimates, commercials, submit | ✅ | — |
| Project Manager / Engineer | Beta: construction budget, variations, CTC, reporting | ❌ | Must-add before Beta |
| Director / Executive | Beta: Director Dashboard, multi-project portfolio | ❌ | Must-add before Beta |
| Supervisor | Mobile PO/invoice approvals | ❌ | Phase 2 likely |
| Accounts Payable | AP/invoice processing | ❌ | Phase 2 |
| Admin | System admin | ✅ | — |
At minimum, PM and Director need to be modelled before Beta — they’re the primary users of Construction Budget, Variations, CTC, and the Director Dashboard.
5. Non-functional requirements — entirely absent from Batch A
Proposal C5 + implicit throughout:
| NFR | Proposal says | Batch A |
|---|---|---|
| Performance | C5.1 — “Fast load times, responsive UI, handles large estimates (1000+ items) without lag” | Silent |
| Security — RBAC | C5.2 MUST — “Role-based access control, audit logging, HTTPS, data encryption at rest” | Partially covered in roles-permissions but no “access control” framing |
| Audit logging | C5.2 MUST — required for Variations, Commercials, Submit, Publish | Flagged as “out of scope for matrix” |
| HTTPS / encryption at rest | C5.2 MUST | Silent |
| Training + materials | C5.3 MUST / C5.4 NEED — “structured training for all Oxcon users; user guides, quick-reference cards, video walkthroughs” | Silent |
| Data migration | C5.5 MUST | Silent |
| Benchmark decommission | C5.6 MUST — “Full cutover. Benchmark licenses terminated. All users on Oxflow.” | Silent |
| Uptime / hosting / DR | Implicit in Essential Support tier: “cloud hosting, DNS/SSL, backups, disaster recovery, security patches, uptime monitoring, staging/production environments” | Silent |
| Real-time collaboration | A12.4 | Silent |
None of this is in Batch A. It doesn’t need full detail today, but a baseline NFR section should exist in the foundation.
6. Scope boundary with Phase 2 — not clarified
The proposal explicitly calls out a Phase 2 Cost Management roadmap:
- AP Approvals
- Invoice Processing
- Subclaims
- Cost Coding
- Bi-directional Xero integration (Batch A says Xero is read-only — proposal says Phase 2 is bi-directional)
- Tender CRM (pipeline tracking, win/loss analysis)
End state: “Workbench is fully replaced. Oxcon runs entirely on Oxflow™ for estimating, forecasting, cost management, and accounting integration.”
Batch A treats Xero and Workbench as permanent integration partners. Proposal says Workbench is replaced in Phase 2. That’s a fundamental scope change Batch A needs to acknowledge (even if the detail is deferred).
7. Honest severity ranking
If you read nothing else from this report:
Must-fix before Batch B starts:
- Add phasing (Alpha / Beta / Release / Phase 2) to every entity and rule
- Add Revision as a first-class concept (cuts across Estimate, Construction Budget, CTC, Variation)
- Add Construction Budget as a distinct entity from Estimate (Beta surface area)
- Add Variation as a full entity with its own lifecycle (Beta, 8 MUST functions)
- Add CTC / FFC concepts (Beta, core Phase 1 value)
- Add Production Rate as a first-class concept (Alpha A4.5)
- Add missing Item Types (Composite, Total/Subtotal, Text heading)
- Add Module concept (multi-methodology per SOQ line) — verify with Oxcon
- Add Project Manager and Director as user profiles
- Add NFR baseline section (performance, security, audit, migration, decommission)
Important but can be absorbed during Batch B/C: 11. Reporting Suite entities 12. AI layer architecture stub 13. Historical Rate library 14. Director Dashboard / portfolio view 15. Construction Programme (distinct from Tender Programme) 16. Workbench live bi-directional architecture 17. Multi-user collaboration model 18. Subcontract full-workflow attributes (beyond just Adjudication) 19. Cost Template / Item Template vs Recipe distinction 20. Risk Items as valued line entities
Can be deferred to Batch D/E: 21. Progress Claim / M&V quantity handling 22. Cash Flow Forecasting 23. Phase 2 Cost Management scope acknowledgement 24. Training & migration deliverables
8. Recommendation on how to proceed
Three options, with my recommendation:
Option A (recommended): Batch A+ pass before Batch B Add the items 1–10 above into Batch A as a minor revision (call it Batch A v2). Roughly 1–2 days of work. Then Batch B proceeds against the corrected foundation.
Option B: Fold into Batch B Don’t do a Batch A+ pass. Let Batch B entity specs cover the new concepts as they come up. Risk: the foundation stays wrong and Batch B keeps discovering context gaps. Entity specs that try to fix foundation issues become bloated.
Option C: Narrow Batch A scope to Alpha only Re-scope Batch A as “Alpha Foundation” and do Batch A-Beta and Batch A-Release later. Risk: creates more paperwork but matches the proposal’s phasing cleanly.
My lean: Option A, because Revision / Construction Budget / Variation touch every downstream spec and are too foundational to defer.
Awaiting your direction before making any changes.