SetupV1V2
Al Khoud Residential Villa

Project Workflow

From signed contract and baseline schedule to verified construction progress and payment.

View Demo Project
1

Project inputs

A construction project begins with exactly two authoritative documents. Everything the product knows is derived from them.

Signed Construction Contract

Extracted at project setup

Extracted
Contract number
CON-2026-0184
Project name
Al Khoud Residential Villa
Client
Ahmed Al Balushi
Contractor
Al Noor Construction LLC
Consultant
Modern Engineering Consultancy
Contract value
OMR 245,000
Start date
15 Sep 2026
Completion date
08 Nov 2027
Contract duration
420 days
Retention
5%
Payment stages
11

Primavera Baseline

Primavera P6 Professional 23.12

Imported
AlKhoud_Villa_Baseline_R0.xer
Data date
15 Sep 2026
Activities
684
WBS packages
27
Milestones
18
Relationships
912
Planned start
15 Sep 2026
Planned completion
08 Nov 2027
Critical activities
42

Figures above are what the XER header declared. This prototype materialises 89 representative activities from that programme — enough to make every screen behave realistically without shipping a 684-row fixture.

eBinaa Project Setup

Contract and baseline combined into one active project.

7 of 9 complete
Contract data extracted
Project parties identified
Primavera baseline imported
WBS created
Activities created
Milestones created
Baseline saved
Stage mapping pendingContractor
Consultant review pendingConsultant

Once setup is approved, Primavera is no longer required for day-to-day operation.

Review Project Setup
2

Who does what, and when

Three parties, four phases. Select any step to see what that party controls and what it produces for the others.

Contractor

Plans, builds, reports progress and requests payment.

Consultant

Inspects, verifies actual progress and certifies stages and payment.

Client

Monitors delivery and approves stages and payment.

3

The loop at the centre

Setup happens once. This repeats until the project is handed over.

The recurring construction cycle

Repeats for every activity, every stage, for the life of the project.

Core product loop
  1. 1System

    Planned Activity

    An activity becomes due against the current programme.

  2. 2Contractor

    Contractor Executes

    The work is carried out on site.

  3. 3Contractor

    Contractor Reports

    Progress claimed, with dated site evidence attached.

  4. 4Consultant

    Consultant Inspects

    A named engineer attends site and records what is there.

  5. 5Consultant

    Consultant Verifies

    Verified progress is set — it may be lower than claimed.

  6. 6System

    eBinaa Updates Verified Progress

    Verified values roll up to WBS, stage and project level.

Stage Complete?

Is verified progress at or above the stage completion threshold?

NOConstruction continues — return to the top of the loop
YESThe stage exits the loop and becomes money
  1. Contractor submits stage completion
  2. Consultant certifies
  3. Client approves
  4. Payment recorded
  5. Next stage
4

The rule that makes it work

One field would destroy the audit trail. Three fields preserve it.

Planned, reported and verified are three different values

They are never merged into a single percent-complete field. This is the product's central discipline.

Planned43.3%
Contractor reported40.1%
Consultant verified36.9%
Variance-6.4%
Unverified claim3.2%

Live figures from Al Khoud Residential Villa. The contractor claims 40.1%; the consultant has verified 36.9%. The project is -6.4% against plan — and 3.2% of the claim is not yet verified, so it cannot enter a payment certificate.

Planned
From the baseline schedule. Where the contract says the work should be.
Contractor reported
What the contractor claims is complete. A claim — never a basis for payment.
Consultant verified
What a named consultant certified on site. The only value that drives money.

Why this matters commercially. A single “percent complete” field makes payment a typed number. Three separate values make it a computed one: due = certified − retention − previously certified. That is the difference between a schedule viewer and a controls system, and it is the property a bank or a court can rely on.

5

Data ownership

Every object in the product has exactly one owner and a defined path to approval.

Data ownership and responsibility

Who creates, who verifies, who approves — for every object in the product.

DataContractorConsultantClientSystemNote
Master ScheduleOwnerApproveView—
WBSOwnerVerifyViewGeneratedCreated by Primavera import
Activity LogicOwnerVerify——Not exposed to the client by default
Activity DurationOwnerVerify——
Contractor Reported ProgressSubmitVerifyView—A claim, not a fact
Consultant Verified ProgressViewOwnerView—The only value that drives money
Site EvidenceSubmitVerifyView—
InspectionSubmitOwnerView—Contractor requests, consultant performs
IssuesSubmitSubmitView—Either party may raise
Schedule RevisionsSubmitApproveViewGeneratedCompletion impact computed
Stage CompletionSubmitVerifyApproveGeneratedReadiness computed from verified progress
Payment RequestSubmitVerifyViewGeneratedValuation computed
Payment CertificationViewOwnerViewGeneratedNet = certified − retention − previously certified
Payment ApprovalViewViewApprove—
Payment RecordViewViewOwnerGeneratedeBinaa records; it does not move money
OwnerCreates and controls the dataSubmitProvides it for someone else to act onVerifyIndependently checks itApproveMakes the binding decisionViewRead-only visibilitySystemGenerated or computed by eBinaa