Information needed to unblock

• Legal holder of client funds (licensed bank, trustee, or operator account)
• Account structure: pooled vs per-project segregation
• Who executes a release instruction and on what authority
• Reconciliation and statement format shown to the counterparty
• Beneficiary of any interest earned on held funds
• Settlement timing and cut-off windows

Options, with the trade-off

1. 1Licensed bank escrow account, per-project segregationStrongest client trust signal and the cleanest reconciliation story; slowest to arrange, and every release depends on the bank's instruction channel and cut-off.
2. 2Third-party trustee holding a pooled account with per-project sub-ledgersOne custody relationship to negotiate and a well-understood structure; the platform's internal sub-ledger becomes the record of truth, so reconciliation discipline carries more weight.
3. 3Operator-controlled client account, segregated in the books onlyFastest to stand up and fully under platform control; weakest trust position and the hardest to defend to a client or an auditor.

Suggested way forward

• Custody: a third-party or bank-held account with per-project visibility. The whole trust story is that funds are held by someone other than the party being paid, and an operator-held account undercuts it.
• Release executor: keep release triggered by certification and executed by the platform as an instruction to the counterparty, with the counterparty as the party that actually moves money. This preserves the no-release-without-certification gate and keeps the loan officer out of the execution path.
• Interest on held funds: assign it explicitly to one named party in writing before launch; leaving it unassigned is the most common source of later dispute.
• Settlement: define one cut-off window and show it on the release surface, so a certified-but-not-yet-settled release reads as expected rather than as a fault.

Direction indicated

• Custody: a third-party trustee holds a pooled account with per-project sub-ledgers; the platform sub-ledger is the record of truth, so reconciliation discipline carries more weight.
• Release executor: release is triggered by certification and issued by the platform as an instruction to the counterparty, which is the party that actually moves money. The loan officer stays out of the execution path.
• Interest on held funds: held by the trustee and apportioned to stakeholders, with an operator setting to adjust the allocation split.
• Settlement: one defined cut-off window, shown on the release surface so a certified-but-not-yet-settled release reads as expected rather than as a fault.

Built in the application

• Custody model built as a third-party trustee holding a pooled client account with a per-project sub-ledger reference (SUBL-<project>).
• Release is triggered by certification and executed by the platform as an instruction to the trustee; the trustee moves the money.
• One settlement cut-off window (16:00 MYT) is computed and shown on release and reconciliation surfaces.
• Interest on held funds is held by the trustee and apportioned using the operator's allocation split setting.

Sequencing

Custody holder and release executor must be answered together — the executor answer is meaningless until the holder is known. Account structure, reconciliation format and cut-off follow from the holder, so they are second-order.

Where it appears today

• Escrow counterparty toggle in operator settings
• Bank / trustee custody panel (greyed)
• Release-executor label on every release surface
• Financier escrow view

Current treatment: Release executed by: system — executor identity pending D-4.

Information needed to unblock

• Trigger conditions for each state and who may set and clear it
• Who initiates a reversal and who authorises it
• Confirmation that a reversal posts a new append-only entry rather than editing one
• Which actions stay available while funds are frozen
• Whether retention and pending claims freeze with the project
• Refund destination account and settlement timing
• Exit path back to an active state and the record left behind

Options, with the trade-off

1. 1One generic hold state plus a reversal entry typeSmallest surface to build and explain; every real-world cause collapses into the same label, so the ledger no longer says why funds stopped.
2. 2Distinct states for frozen, disputed and cancelled, sharing one reversal mechanismThe record explains itself and each state can carry its own permitted actions; three sets of entry and exit rules to define and test.
3. 3Defer exception handling to an operational process outside the ledgerNo build cost now; breaks the core rule that no money moves without a documented ledger object, so it is not recoverable later.

Suggested way forward

• Distinct states, one reversal mechanism. Each state posts an append-only entry on entry and another on exit, so the project's history reads as a sequence rather than a current status.
• Never edit or delete a posted entry to unwind a payment — a reversal is always a new entry that references the original transaction ID.
• While frozen: allow evidence upload, viewing and commentary; block certification, release, claim submission and VO application. State the block on-screen with the reason.
• Refund destination must be the original funding source, recorded at deposit time — deciding it at refund time is how funds go to the wrong party.
• Name a single authorising role per state, distinct from whoever requests it.

Direction indicated

• Follow the suggested way forward: distinct frozen, disputed and cancelled states sharing one reversal mechanism, each posting an append-only entry on entry and on exit.
• A reversal is always a new entry referencing the original transaction ID — no posted entry is ever edited or deleted.
• While frozen: evidence upload, viewing and commentary stay available; certification, release, claim submission and VO application are blocked with the reason shown on-screen.
• Refund destination is the original funding source recorded at deposit time, settled through the third-party trustee per the D-4 direction (trustee-held pooled account with per-project sub-ledgers, platform issues the instruction).
• One named authorising role per state, distinct from the requester.

Built in the application

• Frozen, disputed and cancelled are distinct project states, authorised by the operator only, each posted as an append-only ledger entry.
• Every exception state blocks certification, release, claim submission and variation-order application through the shared release gate; evidence upload and viewing stay open.
• REFUND posts unreleased escrow back to the original funding source recorded at deposit time, settled through the trustee.
• REVERSAL never edits a posted entry — it appends a new entry referencing the original transaction ID, and the balance subtracts refunds and reversals.

Sequencing

Trigger conditions and the authorising role come first — the entry types cannot be defined until you know who fires them. Refund destination and settlement timing follow the recorded D-4 custody direction. D-12 retention release should not be finalised before this, since a frozen project must also freeze retention.

Where it appears today

• Greyed gap-state pills
• Undefined admin role row
• Ledger entry types not yet issued

Current treatment: Greyed states tagged "Reserved design space — D-8". No workflow exists.

Information needed to unblock

• Retention percentage basis, and per-milestone vs per-contract holding
• Defect-liability period length and the event that starts it
• Release trigger: elapsed time, certificate, or client confirmation
• Partial-release rules and the ledger entry type each one posts
• Treatment of unresolved defects at the end of the period
• Conditions under which the final statement is allowed to close at zero

Options, with the trade-off

1. 1Time-based release — retention releases automatically when the defect-liability period elapsesPredictable for the contractor and needs no one to act; releases money even when a defect is open unless a separate hold intervenes.
2. 2Certificate-based release — a final certification releases retentionConsistent with the rest of the product, where certification is the only thing that moves money; retention can sit indefinitely if no one certifies.
3. 3Client-confirmation releaseGives the client the final say and reads well on a trust surface; puts the contractor's last payment entirely in the counterparty's hands with no timeout.

Suggested way forward

• Certificate-based, with a defined elapsed-time backstop so retention cannot be held forever by inaction. This keeps the single rule that certification moves money.
• Hold retention per milestone but present one aggregate held figure — per-milestone holding is what makes partial release explainable later.
• Every partial release posts its own append-only entry referencing the milestone it came from; the final statement is a view over those entries, never a separate calculation.
• An unresolved defect at period end should block release and post a hold entry rather than silently extending the period.
• Allow the final statement to close at zero only when every retention entry has a matching release or hold entry.

Direction indicated

• Follow the suggested way forward: certificate-based retention release, with a defined elapsed-time backstop so retention cannot be held forever by inaction.
• Retention is held per milestone and presented as one aggregate held figure.
• Every partial release posts its own append-only entry referencing its milestone; the final statement is a view over those entries, never a separate calculation.
• An unresolved defect at period end blocks release and posts a hold entry rather than silently extending the period.
• The final statement may close at zero only when every retention entry has a matching release or hold entry.

Built in the application

• 5% of every certified milestone is locked as a RETENTION_HOLD entry at certification; the release entry is posted net of retention.
• Retention held is shown on the escrow position, the ledger and the final statement, derived from the ledger and never stored.
• Retention releases on the completion certificate, with an elapsed-time backstop at the end of the defect-liability period.
• An unresolved defect blocks release and posts a further hold instead of silently extending the period.

Sequencing

Depends on D-8 — a frozen or disputed project must freeze retention too, so the hold mechanism has to exist before the release trigger is finalised. The percentage basis and defect-period length can be settled in parallel; the release trigger is the decision that shapes the screens.

Where it appears today

• Retention line on project finance views
• Final statement conditions
• Completion flow

Current treatment: Retention displayed as a held figure; release mechanics tagged pending.

Information needed to unblock

• Statement and reconciliation format the counterparty expects
• Frequency and direction of reconciliation
• Handling of a mismatch, and who investigates
• Whether the counterparty sees project-level detail or totals only

Options, with the trade-off

1. 1Counterparty statement imported and reconciled against the platform sub-ledgerThe platform owns the reconciliation and can surface a mismatch immediately; it must parse whatever format the counterparty provides and keep up with changes to it.
2. 2Platform export sent to the counterparty, who reconciles at their endLeast build effort; the platform learns about a break late and second-hand, which is the worst position for a custody product.
3. 3Two-way reconciliation with a shared break-resolution queueFastest resolution and the clearest ownership of each break; needs the counterparty's cooperation and a shared process, so it cannot be built unilaterally.

Suggested way forward

• Import the counterparty statement and reconcile against the platform sub-ledger daily, aligned to the D-4 direction that the sub-ledger is the record of truth.
• Show breaks as an explicit count on the finance console rather than hiding a mismatch behind a matching total — a silent reconciliation is not a reconciliation.
• Never resolve a break by editing a posted entry. A correction is a new append-only entry referencing the original.
• Give the counterparty project-level detail. Totals-only reconciliation cannot locate which project a break belongs to.

Built in the application

• Operator and auditor get a trustee reconciliation surface: pooled total, per-project sub-ledger rows and settlement-window status.
• Each row reconciles deposits − releases − retention held − refunds − reversals against the derived held balance.
• Read-only by construction — nothing on the surface posts, edits or moves anything.

Sequencing

Entirely downstream of D-4 — the format, frequency and level of detail are all set by whoever holds the account. Nothing here can be specified before the custody counterparty is named.

Where it appears today

• Custody panel
• Operator finance console reconciliation strip

Current treatment: Greyed panel tagged "Reserved design space — D-4/CZ-6".

Information needed to unblock

• Who is legally entitled to certify a milestone
• Whether the certifier is operator staff, an accredited third party, or client-appointed
• Accreditation evidence captured at onboarding, and who verifies it
• How the certifier is named on the certificate and on the release entry
• Liability position if a certification is later disputed

Options, with the trade-off

1. 1Operator-employed certifierFastest to staff and easiest to hold to a service standard; the operator both certifies and instructs release, which weakens the independence story to a client or a lender.
2. 2Accredited third-party certifier on a panel the operator maintainsIndependent enough to defend, with quality controlled through panel admission; accreditation evidence must be collected, verified and kept current for every panel member.
3. 3Client-appointed certifier per projectStrongest independence in the client's eyes; certification pace and quality vary project by project, and the platform cannot enforce a checklist standard it does not control.

Suggested way forward

• Panel-based accredited third party as the default, with the accreditation record captured at onboarding and shown on the certificate.
• Name the certifier as a person, not a firm, on both the certificate and the linked RELEASE entry — an entry that names only an organisation cannot be defended later.
• Settle the liability position in writing before launch: certification is the event that moves money, so the party bearing the consequence of a wrong certification must be identified.

Built in the application

• Certifier accounts carry a panel accreditation record (body, reference, expiry, who verified it and when), seeded on every certifier account.
• Certification surfaces, the CPC signatory block and RELEASE entries attribute an accredited panel certifier.
• Operator staff never certify — certification stays the certifier persona's only money-moving action.

Sequencing

Answer this before D-7. The checklist standard only binds someone once you know who is signing against it, and the liability position follows from the identity, not the other way round.

Where it appears today

• Inspection console certifier attribution
• Certifier model selector in operator settings
• CPC signatory block
• Certifier reference on RELEASE ledger entries

Current treatment: Labelled placeholder: operator staff / accredited third party / external certifier.

Information needed to unblock

• Confirmation that an auditor persona is wanted
• Who the auditor is: internal, client-appointed, or external
• Scope of records visible, and whether it is project-scoped
• Whether exports are permitted, and in what format

Options, with the trade-off

1. 1Drop the persona — auditors use an operator-generated exportOne fewer login, role boundary and access-consent question; every audit request becomes manual operator work.
2. 2Project-scoped read-only auditor loginSelf-service within a bounded view and easy to explain to a client; someone must decide who assigns the scope and when it ends.
3. 3Operator-wide read-only auditor loginSuits an internal or statutory audit across all projects; the broadest read of personal and financial data in the product, and the hardest to consent for.

Suggested way forward

• Keep the persona, scoped to named projects and assigned explicitly, with the assignment recorded as an event.
• Read-only must mean no state change of any kind — no comments, no acknowledgements, no exports that mutate anything.
• Allow export, but log every export with the auditor, the scope and the timestamp; an audit view without an access record is itself an audit finding.

Built in the application

• Auditor is project-scoped and strictly read-only: ledger, audit trail, exports and trustee reconciliation for assigned projects only.
• No claim, certification, release, retention-release or variation-order control is ever rendered for the auditor.

Sequencing

Get the client's confirmation that the persona is wanted before anything else. Scope, assignment and export rules follow, and they overlap with the SM-3 consent basis wherever an external auditor sees client data.

Where it appears today

• Auditor login and read-only views

Current treatment: Labelled as an inferred persona.

Information needed to unblock

• Confirmation that the persona is in scope
• How a project becomes assigned to an officer, and who assigns it
• Exact read-only boundary, restated as a rule
• Confirmation the officer is neither custody counterparty nor release executor

Options, with the trade-off

1. 1Officer login with assignment by the operatorThe operator controls who sees what and can revoke it; assignment becomes ongoing operational work.
2. 2Officer login with assignment triggered by client consentCleanest consent story, since the client grants the view; access depends on the client acting, and revocation must be handled.
3. 3No officer login — the client shares an export with their lenderNo new persona, no consent surface, no read boundary to enforce; loses the live certification and ledger visibility that makes the lender view valuable.

Suggested way forward

• Keep the persona, with client-consented assignment recorded per project and revocable — this aligns the access with the SM-3 consent basis instead of bolting it on later.
• State the read-only boundary as one rule and enforce it in the UI, not in policy: no certify, no release, no VO approval, no claim action, on any surface or breakpoint.
• Keep the explicit label that the officer is neither the custody counterparty nor the release executor on the portal itself, not only in documentation.

Built in the application

• Financing observer is read-only on assigned projects only, admitted by written client consent, and labelled as such on every surface.
• The loan officer is never the custody counterparty and never the release executor, and never reaches certification, release or variation-order approval controls.

Sequencing

Confirm the persona first, then answer SM-3 alongside assignment — the assignment mechanism and the consent basis are the same decision viewed from two sides. FD-10 facility fields depend on both.

Where it appears today

• Loan officer login and portal
• Assigned-project scoping

Current treatment: User-directed persona; client confirmation pending.

Information needed to unblock

• Whether the designer is a paid party inside the same escrow
• Whether the designer may raise claims or variation orders
• Relationship to the contractor's SOW baseline

Options, with the trade-off

1. 1Read-only collaborator on the contractor's projectNo new payee, no new claim path, minimal build; the designer's own fee sits outside the platform, so the money story is incomplete.
2. 2Paid party on a separate SOW within the same projectComplete picture of who is paid for what, using the existing milestone and release machinery; two baselines per project to keep consistent, and certification of design work is a different exercise from site certification.
3. 3Designer as a sub-line within the contractor's SOWOne baseline and one payee to manage; the designer has no independent standing and depends on the contractor to be paid.

Suggested way forward

• Keep the persona read-only for now. Nothing in the current build depends on the designer being a payee, and adding a second payee class touches custody, certification and the release gate at once.
• If the designer becomes a paid party, use a separate SOW rather than a sub-line, so their claims and variation orders are attributable and independently acknowledged.
• Either way, state on the designer dashboard whether design fees are inside or outside escrow — the current shell leaves it ambiguous.

Built in the application

• The engagement brief now asks whether design sits inside the contractor's scope or on a separate designer SOW.
• On a separate SOW the designer becomes an independently paid party inside the same project, with its own sealed scope line and milestone.
• Designer payments run through the same single release gate: certification first, retention locked, trustee-instructed release.

Sequencing

Answer the paid-party question first; claim rights and the SOW relationship follow directly from it and are not worth specifying beforehand.

Where it appears today

• Designer login and dashboard

Current treatment: Shell interface with no distinct payment-affecting workflow.

Information needed to unblock

• Whether a support role exists separately from the operator
• Whether it can view project or personal data
• Confirmation it can never alter a posted ledger entry
• Audit trail requirement for any support action

Options, with the trade-off

1. 1No separate support role — operator staff handle supportNothing new to define or audit; support work is done with full operator privilege, which is far more access than a support task needs.
2. 2Support role with metadata-only visibilityLeast-privilege and easy to justify to a client; support cannot see enough to resolve some issues without an escalation path.
3. 3Support role with full read and a request-based escalation for any writeResolves most issues directly; full read of personal and financial data across all projects is a significant PDPA exposure.

Suggested way forward

• Define the role explicitly rather than leaving support to run as operator — an undefined role is one that is granted too much in practice.
• Metadata-only by default, with a time-boxed elevated read that requires a named approver and is logged.
• State the invariant in the roles matrix itself: support can never post, alter or reverse a ledger entry, under any escalation.
• Log every support action with the actor, the target record and the reason.

Direction indicated

• A support role with full read and request-based escalation for any write.

Built in the application

• The support role has full read across projects and no write capability of its own; any write requires a time-boxed escalation approved by a named approver.
• Every support action is logged with the actor, the target record and the reason.
• A stated invariant in the roles matrix: support can never post, alter or reverse a ledger entry — for any reason.

Sequencing

Whether the role exists at all comes first. Its data visibility should be set with the D-16 PDPA work, since support is the role most likely to touch identity documents.

Where it appears today

• Support console — escalations and support action log
• Support persona on the simulated login
• Operator roles matrix row

Current treatment: Row present and greyed; no permissions assigned.

Information needed to unblock

• Whether a client engages directly or through a submitted proposal
• Whether a quotation document exists as a separate object before the SOW baseline
• Who may issue and revise a proposal, and how many revisions are on record
• How an accepted proposal becomes SOW v1

Options, with the trade-off

1. 1Direct selection only — the client picks a contractor and the SOW is built straight awayShortest path to a funded project and one fewer document class to version; loses the comparison step clients expect on larger jobs.
2. 2Proposal approval only — every engagement starts as a submitted, revisable quotationGives a clean paper trail from first price to SOW v1; adds a second versioned object that must be kept consistent with the SOW baseline forever.
3. 3Both routes, chosen per project at engagementFits small and large jobs alike; two engagement paths must each be tested, documented and reconciled to the same SOW v1 shape.

Suggested way forward

• Support both, but make the quotation a pre-baseline document rather than a parallel object: acceptance converts it into SOW v1 and it stops being editable from that moment.
• Keep every proposal revision visible after acceptance, in line with the rule that nothing financial is ever silently deleted.
• Restrict issuing and revising a proposal to the contractor, with the client able to accept or reject only — mixed authorship of a priced document is hard to defend later.

Direction indicated

• Both routes stay available and the route is chosen per project at engagement.
• On the proposal route a quotation is a pre-baseline document; client acceptance converts it into sealed SOW v1.

Built in the application

• The engagement brief carries an explicit route choice — direct selection or proposal approval — recorded on the project.
• On the proposal route the quotation is created as a pre-baseline document, and acceptance is the event that seals SOW v1; every superseded revision stays visible.
• Both routes converge on the same sealed SOW v1 shape, so milestone funding, certification and release behave identically afterwards.

Sequencing

Decide whether a quotation object exists at all first. Revision authority and the conversion rule into SOW v1 are meaningless until that is settled, and D-6 template authority is only relevant on whichever route produces the baseline.

Where it appears today

• Alternate proposal-approval engagement screen
• Quotation document that exists only on that route

Current treatment: Direct selection is the demo default; the alternate route is labelled unresolved.

Information needed to unblock

• Whether milestone templates follow an industry standard or are operator-defined
• Whether clients or contractors may add ad-hoc milestones
• Minimum/maximum milestone count and value distribution rules
• Who approves a deviation from the template

Options, with the trade-off

1. 1Operator-defined templates, lockedPredictable payment schedules and consistent certification checklists; poor fit for unusual scopes, and every exception becomes a support request.
2. 2Operator templates as a starting point, freely editable per projectFits any scope and speeds up SOW building; value distribution can drift toward front-loaded schedules that leave too little held at the end.
3. 3Adopt a published industry milestone standardRemoves the authority question entirely and is easy to explain; the platform inherits a standard it cannot change and must track its versions.

Suggested way forward

• Operator templates as a default that can be edited, with guardrails rather than a lock: a minimum milestone count and a cap on any single milestone's share of contract value.
• Allow the contractor to propose ad-hoc milestones and require client acknowledgement, so the change lands as a versioned SOW event rather than an untracked edit.
• Do not claim industry-standard authority in copy unless a named standard is actually adopted.

Direction indicated

• Operator milestone templates are an editable default with guardrails, not an imposed standard.

Built in the application

• Operator templates prefill the milestone schedule and stay editable, with guardrails: a minimum milestone count and a cap on any single milestone's share of contract value.
• Contractor-proposed ad-hoc milestones require client acknowledgement and land as a versioned SOW event.
• No industry-standard authority is claimed anywhere in the copy — the template is described as a platform default.

Sequencing

Second-order to D-5 — the template only attaches to whichever route creates SOW v1. Deviation approval follows once the editability question is answered.

Where it appears today

• SOW builder milestone presets
• Payment-schedule generation

Current treatment: Presets shown as generic templates with no authority claimed.

Information needed to unblock

• Which checklist standard governs an inspection, and who publishes it
• Whether the standard varies by project type or size
• Whether items are pass/fail only or graded
• Whether an item may be waived, and by whom
• Version control of the checklist over time

Options, with the trade-off

1. 1Operator-published checklist, versioned in-platformFull control over content and version history, and it can be tuned per project type; the operator owns the technical defensibility of every item.
2. 2Adopt an external published standard by referenceStrong authority claim with no drafting burden; the platform must track external revisions and cannot adapt items to a project that does not fit.
3. 3Certifier-supplied checklist, recorded as an attachmentMatches how independent certifiers already work; comparability across projects is lost and the platform cannot enforce a minimum standard.

Suggested way forward

• Operator-published and versioned, with the version stamped onto every certificate and its linked RELEASE entry — a certificate that does not name a checklist version cannot be re-read later.
• Pass/fail only. A graded item invites argument about what score releases money, and the release gate is binary.
• Allow a waiver, but record it as a named, reasoned event on the certificate rather than a silently skipped item.

Direction indicated

• The certification checklist is operator-published and versioned, with pass/fail outcomes only.

Built in the application

• Each checklist carries a published version; the version in force is stamped onto every certification record, certificate and its RELEASE ledger entry.
• Outcomes are pass or fail only — no partial scoring.
• A waiver is permitted but is recorded as a named, reasoned event on the audit trail, never a silent pass.

Sequencing

Depends on D-3 — the standard has no force until the signing party is known. Grading, waiver authority and versioning are all second-order to that.

Where it appears today

• Checklist standard selector in the inspection console
• Certification documents

Current treatment: Template names shown with the note "authority undecided — D-7".

Information needed to unblock

• Whether pre-construction and final certification are full workflows or documents only
• Item-level content for each, and who signs them
• Whether either one gates a payment

Options, with the trade-off

1. 1Documents only — captured as an attachment, no workflowAlmost no build cost and no new gate; the items are not verifiable in-platform, so they add little beyond a filed PDF.
2. 2Full checklist workflows mirroring milestone certificationConsistent behaviour and a real record at both ends of the project; two more checklist standards to author, version and maintain.
3. 3Full workflow at final certification only, document at pre-constructionPuts the effort where money is at stake; the pre-construction step stays weaker than the trust framing suggests.

Suggested way forward

• Full workflow for final certification, since it is the natural trigger for the D-12 retention release and needs to be defensible. Keep pre-construction as a document for now.
• Whichever depth is chosen, name the signatory — an unsigned checklist adds no evidentiary weight.
• Be explicit about whether either checklist gates a payment; a checklist that looks like a gate but is not is worse than no checklist.

Direction indicated

• Full checklist workflows mirroring milestone certification.

Built in the application

• Pre-construction capture is document-only and explicitly marked as not a payment gate.
• Final certification runs a full checklist workflow mirroring milestone certification, signed by the accredited panel certifier.
• Final certification is the trigger for the retention release already built for D-12, with the elapsed-time backstop retained.

Sequencing

Second-order to D-7 and D-12. The final certification checklist should be authored under the same standard authority as milestone checklists, and its role only becomes clear once the retention release trigger is chosen.

Where it appears today

• Pre-construction verification checklist
• Final project certification checklist

Current treatment: Items carry "(deck-only depth — D-17)".

Information needed to unblock

• Which events notify which persona
• Whether email, SMS or push is required, and who owns delivery
• Escalation and reminder rules for unactioned items
• Retention period for the notification record

Options, with the trade-off

1. 1In-app feed onlyNo delivery infrastructure, no deliverability problem, no consent question; users only learn about an event when they next open the app.
2. 2In-app plus email for payment-affecting eventsReaches people who are not in the app daily, which matters for certification and release; needs a delivery owner and a bounce-handling story.
3. 3Full multi-channel with per-user preferencesBest reach and user control; the largest surface to build and the one most likely to leak project detail into an unsecured channel.

Suggested way forward

• In-app plus email, restricted to payment-affecting events: claim submitted, certification issued, release executed, VO awaiting approval, retention released.
• Keep external messages content-free — an event name and a link, never amounts, client names or project detail. An email is not a role-scoped surface.
• Define one escalation rule for unactioned approvals rather than per-event reminders; a stalled VO approval is the only case that reliably needs chasing.
• Set a notification retention period alongside the PDPA work in D-16, since the feed itself is personal data.

Direction indicated

• Full multi-channel notifications with per-user preferences per event class.

Built in the application

• An event-to-persona matrix defines who is notified for each event class, with per-user channel preferences for in-app, email and SMS.
• External messages are content-free: event name and link only — never amounts, client names or project detail.
• One escalation rule for unactioned approvals, plus a stated retention period for the notification record.
• No external delivery channel is integrated — channels are simulated preferences only.

Sequencing

The event-to-persona matrix comes first and is independent of channel. Channel choice depends on it, and the retention period should be settled with D-16 rather than separately.

Where it appears today

• Notification preferences screen — event class × channel matrix
• In-app notification feed
• Loan-officer alerts

Current treatment: In-app feed only; no external delivery channel exists.

Information needed to unblock

• Whether supplier payments sit inside the same escrow ledger
• Supplier onboarding and verification scope
• Link between purchase records and milestone claims
• Whether material cost changes create a variation order automatically
• Phase in which procurement enters the product at all

Options, with the trade-off

1. 1Out of scope — remove the supplier surface entirelyKeeps the product one clean story about contractor payment; loses the material-cost visibility that drives many variation orders.
2. 2Read-only procurement records attached to milestones, no supplier paymentExplains cost movements without touching custody; suppliers get no account and no incentive to keep the records accurate.
3. 3Full supplier ecosystem with suppliers paid from the same escrowThe most complete picture of where money goes; adds a second payee class, supplier verification, and a much larger custody and reconciliation problem.

Suggested way forward

• Keep it a later phase and keep the surface exactly as it is now — greyed and labelled — rather than removing it, so the roadmap position stays visible without implying capability.
• If it does enter, start with read-only procurement records linked to milestones. Cost visibility is most of the value and none of the custody risk.
• Do not auto-create a variation order from a material cost change. A VO is an agreement between two parties; deriving one from a price feed would post an unacknowledged change to the payment schedule.

Direction indicated

• Full supplier ecosystem, in scope, with suppliers paid from the same project escrow.
• A material price change never auto-creates a variation order; procurement is confirmed as a scope in its own right.

Built in the application

• Supplier accounts are a first-class party with their own ledger view of what was ordered, delivered and paid.
• Sourcing workflow: request → supplier quote → acceptance → purchase order linked to a milestone → delivery confirmation → simulated payment from the same project escrow, each step a ledger-linked record.
• Supplier payments carry their own transaction IDs and payee and are included in the derived escrow balance.
• A price change raises a flagged notice with a deliberate 'Raise variation order' action — it never changes the payment schedule by itself.

Sequencing

Decide the phase before anything else here — onboarding scope, claim linkage and escrow participation are all unanswerable until procurement is confirmed as in scope. D-18 supplier naming only becomes a live question once this is a yes.

Where it appears today

• Greyed Supplier account row
• Disabled "Procurement Ecosystem — unavailable" panel in operator settings
• Tagged card on the operator overview

Current treatment: Labelled "future phase — timing pending decision D-9". No supplier flow exists.

Information needed to unblock

• Whether any assistive feature is in scope at all
• If in scope: which surface, and whether output ever touches a payment decision
• Human review requirement before anything is recorded

Options, with the trade-off

1. 1Out of scopeNothing to explain, defend or review; forgoes drafting help on documents that are repetitive to produce.
2. 2Drafting assistance only, on non-payment surfacesUseful on scope descriptions and summaries with no exposure to the release gate; the boundary must be enforced in the product, not just stated.
3. 3Assistance on evidence or certification reviewHighest potential leverage; output would sit next to a payment decision, which is the hardest position to defend and the least appropriate for a trust product.

Suggested way forward

• Keep it to the single roadmap card for now. The product's claim is documentary certainty, and an assistive feature next to the release gate works against that claim.
• If anything ships, restrict it to drafting on non-payment surfaces and require an explicit human save before any output becomes a record.
• Never let generated output be the basis of a certification, a claim approval or a ledger entry.

Direction indicated

• Assistive drafting is in scope, on non-payment surfaces only.

Built in the application

• Drafting assistance appears only on non-payment surfaces (brief text, scope descriptions, site notes) and always requires an explicit human save before anything becomes a record.
• A stated hard rule: generated output can never be the basis of a certification, claim approval, variation-order decision or ledger entry.
• No AI service is integrated — the surface is a labelled simulated placeholder.

Sequencing

The in-scope question is the only one that matters now; surface and review rules are meaningless before it is answered.

Where it appears today

• Single roadmap card on the operator overview

Current treatment: One card labelled "under evaluation — decision D-10". No AI feature exists.

Information needed to unblock

• Whether a native app is in scope, and for which personas
• Whether offline evidence capture is required on site
• Camera, file and location capture expectations
• Push notification requirement versus in-app feed only

Options, with the trade-off

1. 1Responsive web onlyOne codebase, instant updates, no store review; no offline capture and no push, which are the two things site work actually asks for.
2. 2Responsive web plus an installable web app with limited offline captureCovers the site-connectivity gap without a second codebase; offline queuing of evidence adds real sync and conflict handling.
3. 3Native app for site personas, web for everyone elseBest camera, offline and push behaviour for certifiers and contractors; a second build, release process and platform surface to maintain.

Suggested way forward

• Stay responsive web and treat the installable route as the first step if offline capture proves necessary — the current mobile shells already cover every persona at phone width.
• Confirm whether site connectivity is genuinely a problem before committing to offline. If evidence can be captured in the phone's camera roll and uploaded later, no offline queue is needed.
• Keep notifications in-app until SM-2 settles routing; a push requirement is a delivery-channel decision, not a form-factor one.

Direction indicated

• Stay responsive web, and add offline capture for site personas.

Built in the application

• An installable app shell plus an offline evidence-capture queue for site personas, with visible queued / synced state per item.
• Nothing financial is ever queued offline — only evidence capture, which is submitted once back online.

Sequencing

Answer the offline-capture question first — it is the only requirement that genuinely forces a form-factor change. Push depends on SM-2, not on this decision.

Where it appears today

• Footer disclaimer
• Offline capture placeholder in evidence upload
• Mobile shells

Current treatment: Responsive web only; offline capture is a labelled placeholder.

Information needed to unblock

• Whether real supplier or product brands may ever appear
• Commercial or consent basis for naming a third party
• Naming convention for generic material descriptions

Options, with the trade-off

1. 1Generic descriptions only, permanentlyNo consent or endorsement exposure at all; SOW line items stay vaguer than a contractor would write them in practice.
2. 2Free-text naming entered by the contractor, with a disclaimerMatches how scopes are actually written and needs no supplier relationship; the platform displays third-party brands it has no consent to use.
3. 3Named brands only where a commercial or consent basis existsDefensible and opens a future supplier relationship; requires a consent register and a review step before any name goes live.

Suggested way forward

• Keep generic descriptions in all seeded and demo content — no real brand should appear anywhere in the prototype.
• If contractor-entered naming is allowed in production, treat the entered text as user content with a clear disclaimer, and never present it as a platform recommendation or endorsement.
• Agree one naming convention for generic materials now (category, grade, dimension) so line items stay comparable across projects.

Direction indicated

• Supplier naming goes live, with one standard naming convention for generic materials.

Built in the application

• One naming convention for every catalogue item: Category · Grade · Dimension. No real brand names anywhere.
• Each supplier carries a display choice — whether the supplier profile is shown at all — set per supplier.
• Every listing states that it is not a platform recommendation or endorsement.

Sequencing

Only becomes a live decision if D-9 brings procurement into scope. Until then the generic convention is the whole answer.

Where it appears today

• Material and supplier references in SOW line items and evidence

Current treatment: Generic placeholder names only — no real brands anywhere.

Information needed to unblock

• Whether any financing product is in scope at all
• Which facility attributes are legitimate to display, and their source
• Who may see facility data and on what consent basis
• Confirmation that no figures, rates or limits appear in user flows

Options, with the trade-off

1. 1Remove financing fields entirelyEliminates any implication of a lending product; the loan officer persona loses the context that makes their view meaningful.
2. 2Keep facility fields as non-financial reference only — facility reference, status, linked projectEnough context for the officer with no figures on screen; requires discipline to keep amounts, rates and limits permanently out.
3. 3Full facility data including amounts and drawdownMost useful to a lender; introduces figures into user flows and moves the product toward a financing surface it does not claim to be.

Suggested way forward

• Non-financial reference fields only. Facility reference, status and linked project give the officer their bearings without displaying a single figure.
• Confirm the source of any displayed attribute — a facility field with no stated origin cannot be trusted or corrected.
• Keep every value seeded and every edit greyed until FD-1 and SM-3 are settled; a lender-facing data surface without a consent basis is the riskiest screen in the product.

Direction indicated

• Full facility data, including financed amount and drawdown, gated by client consent.

Built in the application

• Facility cards show full facility data — reference, type, financed amount and drawdown schedule — with each attribute carrying its stated source and all edits greyed.
• Visibility is gated by per-project, revocable client consent; withdrawal closes the officer's view immediately.
• Shared fields are enumerated at summary granularity, so the client can see exactly what the financing observer sees.

Sequencing

Depends on SM-1 — if the loan officer persona is not confirmed, these fields have no audience. The consent basis from SM-3 must exist before any facility data is shown against a real client project.

Where it appears today

• Financier facility cards with drawdown schedule
• Operator / loan-officer facilities page

Current treatment: Seeded placeholder values, edits greyed, no lending product functionality.

Information needed to unblock

• Identity verification depth per persona, and the evidence collected
• Session, device and MFA requirements
• PDPA consent, retention and deletion handling
• Who inside the operator may view identity documents
• Audit requirements for access to personal data

Options, with the trade-off

1. 1Email and password with MFA, no identity verificationQuickest to stand up and lowest personal-data burden; the platform cannot say who anyone actually is, which is hard to reconcile with holding client funds.
2. 2Tiered verification — light for viewers, documented identity for parties who move or receive moneyProportionate and keeps the document-handling population small; two onboarding paths to build, and the tier boundary must be defensible.
3. 3Full KYC for every account at signupStrongest position with a custody counterparty; heavy signup friction and the largest personal-data retention and deletion obligation.

Suggested way forward

• Tiered verification keyed to money movement: anyone who deposits, is paid, or certifies is verified; auditors and read-only viewers are not.
• MFA mandatory for every persona that can trigger or approve anything, since a compromised certifier account is a payment event.
• Restrict identity-document access to a named operator role and log every view — under PDPA, unlogged access to identity documents is the weakest point to defend.
• Set retention and deletion periods per document class at the same time as collection; retrofitting deletion onto stored identity documents is materially harder.

Direction indicated

• Verification is tiered and keyed to money movement; MFA for anyone who can trigger or approve.

Built in the application

• The security posture page states the tiering: view-only personas verify lightly, anyone who can trigger or approve money movement carries the highest tier.
• MFA is stated as required for claim submission, certification and variation-order approval.
• Identity-document access is limited to one named role, with every view logged.
• Labelled posture only — no real authentication, KYC, MFA or PDPA control is implemented or claimed.

Sequencing

FD-1 first — the regulatory posture sets the minimum verification depth, and choosing a KYC tier before that risks doing the work twice. The custody counterparty from D-4 may also impose its own requirements. PDPA retention rules can be drafted in parallel.

Where it appears today

• Every login surface
• Security settings page
• Account vetting screens

Current treatment: "Simulated — real auth/KYC/MFA pending D-16/PDPA" on all login surfaces.

Information needed to unblock

• Whether holding client funds requires a licence or a licensed partner
• Permitted description of the escrow arrangement in user-facing copy
• Disclosures required on payment and custody screens
• Jurisdictional scope beyond Malaysia, if any

Options, with the trade-off

1. 1Operate through a licensed partner that holds the fundsThe licence obligation sits with the partner and the platform stays a software provider; the partner controls settlement pace and the commercial terms of custody.
2. 2Seek the platform's own licence or approvalFull control of the custody experience and the strongest independent position; long, expensive, and it changes what the product can say about itself only once granted.
3. 3Structure so that the platform never holds client fundsRemoves the licensing question; also removes escrow, which is the product's central promise.

Suggested way forward

• Take formal Malaysian legal advice on whether the arrangement constitutes holding client funds before any copy describes it — this is the single decision most likely to force a rewrite of user-facing language.
• Plan for the licensed-partner route, which is consistent with the D-4 direction of a third-party trustee holding the account.
• Until advice lands, keep every surface exactly as it is: no licensing, regulatory or protection claim anywhere, and no implication that funds are government- or scheme-protected.
• Fix the jurisdictional scope at Malaysia only; each additional jurisdiction reopens the whole question.

Direction indicated

• Malaysia-only scope, with a licensed-partner route planned and no licensing claim anywhere.

Built in the application

• The posture surface states Malaysia-only scope and the intent to operate money movement through a licensed partner.
• No licensing, protection, guarantee or regulatory-approval claim appears anywhere in the product.

Sequencing

The first decision in this group. D-16 verification depth and the permitted wording on every finance surface both follow from it, and the D-4 custody route must be compatible with whatever it concludes.

Where it appears today

• Footer
• Every finance surface
• Landing hero

Current treatment: No regulatory or licensing claim is made anywhere — FD-1 pending.

Information needed to unblock

• Legal basis and consent wording for sharing project data with a lender
• Exactly which fields are shared, and at what granularity
• Whether consent is per project and revocable
• Record kept of each consent event

Options, with the trade-off

1. 1Consent captured once at onboarding, covering all projectsSimplest to collect and never blocks an officer; a blanket consent is the weakest form and the hardest to defend under PDPA.
2. 2Per-project consent, revocable, captured in-appSpecific, revocable and auditable — the strongest position; the officer's view can disappear mid-project when consent is withdrawn.
3. 3Consent handled in the lender's own facility documentation, outside the platformNo consent surface to build; the platform shares data on a basis it cannot evidence, and cannot honour a withdrawal it never sees.

Suggested way forward

• Per-project, revocable, captured in-app, with each grant and withdrawal posted as its own record — consent that cannot be evidenced is the same as no consent.
• Enumerate the shared fields explicitly and share summary granularity by default: milestone status, certification status, ledger entry type and date. Withhold personal detail unless it is specifically consented.
• On withdrawal, close the officer's view immediately and leave the access history intact.
• Draft the consent wording with the same legal advice that resolves FD-1, rather than in isolation.

Direction indicated

• Per-project, revocable client consent captured in-app.

Built in the application

• Consent is captured per project and is revocable at any time; each grant and withdrawal is its own record.
• Withdrawal closes the financing observer's view immediately, while the access history is retained.
• The consent screen enumerates the shared fields at summary granularity.

Sequencing

Answer with SM-1 — the assignment mechanism and the consent basis are one decision. Both depend on the FD-1 posture for wording, and FD-10 facility visibility cannot go live before this is settled.

Where it appears today

• Loan-officer portal
• Certification and ledger visibility for financiers

Current treatment: Data-sharing basis labelled undefined.