One place for
the project rules.

Four request types

Support purchase requests (PR), change requests (CR), sourcing requests (SR) and emergency requests (ER).

Applies to

Requests and purchase orders

How to check

Create each type and verify its distinct intake and lifecycle.

Source: CALL-0910 (00:00:30-00:01:23)

Save and resume

Users can save unfinished requests and resume without losing their work.

Applies to

Requests and purchase orders

How to check

Leave a partially entered request and reopen it with the entered values intact.

Note: Autosave versus explicit save was left to implementation; no automatic draft-deletion deadline was agreed.

Source: CALL-0910 (00:01:36-00:02:17)

Request reference

Every request has a unique reference usable for status lookup before a PO exists.

Applies to

Requests and purchase orders

How to check

Find an unapproved request by its requisition reference without assigning an ordinary PO early.

Source: CALL-0910 (00:21:17-00:21:58)

Optional small purchase requests

A PR below $1,000 is optional but must be allowed. When no PO is requested, accounting can use the job number.

Applies to

Requests and purchase orders

How to check

Submit a $300 PR successfully and explain the optional job-number path.

Note: This replaces any earlier interpretation that the minimum prohibits small PRs.

Source: CALL-0924 (00:01:35-00:03:22)

No minimum change amount

A CR against an existing PO is allowed even when its change is below $1,000.

Applies to

Requests and purchase orders

How to check

Accept a $300 change against a $100,000 PO without a minimum-amount blocker.

Source: CALL-0924 (00:02:25-00:02:51)

Urgency flag

PR, CR and SR can be marked urgent for Procurement prioritization. ER already represents emergency priority.

Applies to

Requests and purchase orders

How to check

Verify urgency can be set on all three types and is visible to Procurement.

Note: Urgency does not establish an approval bypass, automatic escalation or promised response time.

Source: CALL-0923 (00:17:09-00:19:36)

Lean purchase intake

Remove the general Supporting information free-text field from the first release while keeping quote handling and specific required reasons.

Applies to

Requests and purchase orders

How to check

Ordinary purchase intake has no generic purchase-justification box; emergency and over-budget reasons remain.

Source: CALL-0923 (00:21:53-00:25:57)

Project required

Every request identifies the project it concerns.

Applies to

Requests and purchase orders

How to check

Attempt each request type without a project and verify that it cannot be submitted.

Source: CALL-0910 (00:01:15-00:01:23) · CALL-0923 (00:13:15-00:13:42) · CALL-0929 (00:17:11-00:17:19)

Current approval breakpoint

The current ordinary purchase breakpoint is $50,000. PM authority includes exactly $50,000; amounts above it require the full senior route.

Applies to

Approval authority and routing

How to check

On the approval tax basis, test $49,999.99, $50,000 and $50,000.01; only the last requires the above-PM route.

Note: Current common senior settings do not introduce separate $100,000 or $250,000 shortcuts and do not cap the purchase at $50,000.

Source: CALL-0910 (00:39:00-00:40:32) · CALL-0923 (00:07:11-00:09:35) · CALL-0929 (00:17:51-00:18:09)

Complete sequential route

Above PM authority, approval follows PM, project director, district manager, then executive. Each required stage waits for the previous stage. A project director or district manager stage with no one assigned, or whose assigned account is deactivated, is skipped and recorded on the request.

Applies to

Approval authority and routing

How to check

For an above-limit coordinator request, assert all four stages in order and no premature later-stage notice. With the project director or district manager slot blank or naming a deactivated account, assert that stage is skipped, recorded on the request, and routing continues to the next stage.

Note: Do not stop at DM. Equal senior values do not cap the allowed purchase at $50,000. Only the project director and district manager stages may be skipped; the PM and executive stages stay required, a name that matches no account or several accounts is still refused, and nothing is approved automatically. Amended October 18, 2026 for the October 16 client request.

Source: CALL-0916 (00:00:08-00:00:35) · CALL-0923 (00:08:07-00:09:35) · CALL-1016 (Project director and District manager discussion)

CEO default and COO replacement

Use CEO as the default final approver; Procurement can reroute to COO when CEO is unavailable.

Applies to

Approval authority and routing

How to check

Verify default CEO routing and an explicit Procurement COO substitution with recorded history.

Source: EMAIL-0916 (Reply 1) · CALL-0910 (00:39:32-00:39:57)

PM submission approval

A target-project PM submission counts as PM approval, including when the request must continue above the PM limit.

Applies to

Approval authority and routing

How to check

A PM-submitted $80,000 request begins with PD; an in-limit PM request does not need another PM click.

Source: EMAIL-0916 (Reply 2) · CALL-0916 (00:00:39-00:00:59; 00:17:40-00:17:59)

Project assignments drive routing

Populate approvers from the selected project. Requesters do not freely pick the PM or senior approvers.

Applies to

Approval authority and routing

How to check

Change the project and verify its configured route appears without allowing requester-selected approvers.

Source: CALL-0910 (00:41:19-00:41:35; 00:43:43-00:44:29)

Editable authority

Maintain people, acting roles, role limits and project assignments in settings without editing application logic.

Applies to

Approval authority and routing

How to check

Change a configured role assignment and limit, then verify a new request follows the updated configuration.

Note: Real names, limits beyond the agreed breakpoint and assignments are setup data, not values to fabricate.

Source: CALL-0910 (00:13:04-00:15:16)

Membership is not approval authority

Project coordinators and site superintendents can initiate requests; membership or a directory job title alone does not grant approval authority.

Applies to

Approval authority and routing

How to check

A coordinator member can submit and the target-project PM receives approval work.

Source: CALL-0916 (00:31:13-00:32:05; 00:35:24-00:35:52)

Preconstruction route

Preconstruction can initiate across projects, but purchases follow the target project PM and applicable senior approvals regardless of the initiator title.

Applies to

Approval authority and routing

How to check

A preconstruction director initiates an in-limit project purchase and PM review is required.

Source: CALL-0916 (00:33:34-00:38:50)

Procurement-originated project purchases

Procurement-originated project purchases must receive project PM review; Procurement personal authority must not bypass it.

Applies to

Approval authority and routing

How to check

Before enabling this originator path, test in-limit and above-limit purchases for PM review and the normal applicable route.

Note: Policy is confirmed, implementation was explicitly deferrable. Until fixed, Procurement staff avoid originating project requests; do not infer delivery from this confirmed status.

Source: CALL-0929 (00:24:37-00:25:48)

Interim Procurement restriction

Until Procurement-originated PM routing is fixed, Procurement does not originate project purchase requests.

Applies to

Approval authority and routing

How to check

Acceptance instructions state the restriction and do not advertise this path as safely available.

Source: CALL-0929 (00:25:17-00:25:48)

Manual absence rerouting

Procurement can manually redirect approvals when the assigned approver is absent.

Applies to

Approval authority and routing

How to check

Verify Procurement can deliberately reroute an affected request and the requester cannot select arbitrary approvers.

Source: CALL-0910 (00:42:09-00:44:16)

Self-service delegation later

Self-service vacation delegation is a future option, not a first-release requirement.

Applies to

Approval authority and routing

How to check

Do not fail current release solely for absence of personal vacation-delegate settings.

Source: CALL-0910 (00:42:52-00:43:43)

Inclusive PM boundary

Treat up to $50,000 as inclusive PM authority, with escalation only above that boundary under the current policy.

Applies to

Approval authority and routing

How to check

Verify an exactly $50,000 approval amount remains within PM authority, including in-limit PM submission approval.

Note: Resolved on review using repeated up-to and within wording, including the latest call. Do not perpetuate older secondary audits that left this boundary open. Small-PR optionality is separately defined in REQ-004.

Source: CALL-0910 (00:13:21; 00:40:25) · CALL-0916 (00:11:17-00:11:32) · CALL-0929 (00:18:00-00:18:09)

Senior self-approval edge cases

The complete policy for PD, DM or executive submissions, multiple simultaneous project roles and any senior shortcut is not fully established by the calls.

Applies to

Approval authority and routing

How to check

Human confirmation required for these cases; do not promote current generic self-approval code or the old flow to policy.

Source: AUDIT-QUESTIONS (Rows 4-5) · CALL-0916 (00:00:39-00:01:36) · SERVER-WORKFLOW (routeFor)

Remove confusing authority labels

Remove the confusing No limit control without changing the agreed sequence or imposing a new maximum purchase amount.

Applies to

Approval authority and routing

How to check

With all role values at $50,000, a larger purchase still reaches PD, DM and executive in sequence.

Source: CALL-0923 (00:07:11-00:10:17)

Rejection reason and visibility

An approver can reject with a mandatory reason. Notify the requester and earlier approvers of the rejection and reason.

Applies to

Approval authority and routing

How to check

Block blank rejection, persist the reason, and check recipients include requester and prior approvers.

Note: These are informational notices, not an automatic restart of prior approvals. Detailed resubmission semantics require their own evidence.

Source: CALL-0916 (00:18:46-00:20:00) · CALL-0923 (01:05:04-01:06:19)

Line budgets and variance

Collect line budgets and show total budget against the request amount, including variance amount and percentage.

Applies to

Money, budgets, taxes and credits

How to check

Use multiple lines and verify summed budget, request value and variance in the review.

Source: CALL-0910 (00:02:24-00:03:09)

Over-budget explanation

Require a reason when a request is over budget and make it available to approvers.

Applies to

Money, budgets, taxes and credits

How to check

Block an over-budget request without a reason and show the saved reason in approval review.

Source: CALL-0910 (00:03:09-00:03:56)

Approver budget snapshot

Give approvers a concise budget snapshot with variance amount and percentage, red for over budget and green for under budget, plus the over-budget reason.

Applies to

Money, budgets, taxes and credits

How to check

Inspect the actual approver-facing notification or summary, not only the intake screen.

Note: Earlier audit found incomplete email snapshot fields. Verify current output rather than assuming templates are complete.

Source: CALL-0910 (00:02:45-00:03:56) · CALL-0923 (00:22:20-00:23:19)

Approval tax basis

Include applicable PST and HST in the approval amount; exclude GST from that approval basis.

Applies to

Money, budgets, taxes and credits

How to check

Test a pre-tax amount below authority that exceeds it after applicable PST or HST; GST alone must not trigger that increase.

Source: CALL-0910 (00:18:22-00:19:33; 00:39:11) · CALL-0923 (00:29:14-00:29:46)

Project province defaults

The selected project province drives configured tax defaults and rates, including the first detailed line.

Applies to

Money, budgets, taxes and credits

How to check

Select a configured project and verify initial line defaults without manual tax selection; repeat after project changes.

Source: CALL-0923 (00:27:01-00:29:46; 00:31:45-00:34:49) · CALL-0929 (00:16:21-00:17:19)

Tax inheritance on added lines

New lines inherit the first line tax selections while each line remains editable for applicable exceptions.

Applies to

Money, budgets, taxes and credits

How to check

Change first-line applicability, add a line, then independently edit its taxes.

Source: CALL-0929 (00:16:49-00:17:02) · CALL-0923 (00:33:39-00:34:49)

HST exclusivity

HST cannot be combined with GST or PST; GST and PST can coexist where configured.

Applies to

Money, budgets, taxes and credits

How to check

Select HST after GST/PST and verify exclusivity in UI and submitted data.

Source: CALL-0923 (00:28:11-00:28:56)

Explicit exemption

Each detailed purchase line requires a tax selection or explicit Tax exempt. Tax exempt means no selected taxes.

Applies to

Money, budgets, taxes and credits

How to check

Block an empty choice and verify exemption clears taxes; do not apply line-tax validation to minimal ER intake.

Source: CALL-0924 (00:15:00-00:15:48) · CALL-0923 (00:13:01-00:13:43)

Per-line applicability exceptions

Allow users to remove normally applicable tax selections for a genuine exception, including PST-only exemption without removing GST.

Applies to

Money, budgets, taxes and credits

How to check

Verify a configured GST/PST line can retain GST while removing PST.

Source: CALL-0923 (00:31:00-00:34:49)

Configured rates, not casual guesses

Maintain tax rules centrally by province; do not make requesters re-enter rates or derive additional province rules from casual call examples.

Applies to

Money, budgets, taxes and credits

How to check

Verify the configured table drives calculations and missing mappings remain explicit.

Note: Supplied table: BC/MB GST 5%, PST 7%; SK GST 5%, PST 6%; ON HST 13%; NB HST 15%; NS HST 14%; NU/NT/AB/YK GST 5% with no provincial tax row. These are supplied reference values, not independently verified current law. No Quebec row was supplied.

Source: CALL-0923 (00:30:31-00:34:49) · REF-TAX (Province table)

Finance validation inputs

Accounting must validate unresolved tax exceptions, arithmetic examples, rounding and financial mappings.

Applies to

Money, budgets, taxes and credits

How to check

Human confirmation required for unspecified cases; compare calculations with approved finance examples.

Note: The calls define approval tax inclusion but do not explicitly define whether entered budgets include those taxes. Keep this distinction visible without inventing a tax rule.

Source: CALL-0916 (00:24:41-00:25:05) · AUDIT-QUESTIONS (Rows 16-19 and User clarification after the audit)

Legitimate credits

Preserve legitimate negative credit lines and their signed financial effect in requests and PO history.

Applies to

Money, budgets, taxes and credits

How to check

Process a credit against an existing PO and verify it reduces the combined amount without erasing original lines.

Note: Credits are evidenced by the historical client PO, not newly specified by September 24. Representation and approval magnitude are separate implementation choices.

Source: REF-PO (PAGE 1, lines 012 and 017; PAGE 2, line 018) · REF-EMAILS (PO example and negative credit lines)

Received-value floor

A revised PO must not fall below the amount already received against it.

Applies to

Money, budgets, taxes and credits

How to check

Reject the source example reducing a $100,000 PO to $50,000 after $75,000 has been received.

Note: The client confirmed protection against reducing an order below received value. The subtotal accounting basis and unknown-balance blocking mechanism are implementation safeguards in FIN-014, not verbatim client accounting decisions.

Source: EMAIL-0916 (CRs: received-amount red flag)

Verified receipt comparison

The implementation contract compares revised subtotal excluding taxes with verified received subtotal and blocks a reduction when that receipt balance is unknown.

Applies to

Money, budgets, taxes and credits

How to check

Verify reductions with unknown receipt balances are blocked pending verified subtotal and source note. Verify recorded zero is distinguished from unknown, and positive received subtotal is compared with revised subtotal, never the approval total including PST/HST.

Note: The client confirmed the general received-value floor only. Subtotal basis, source-note verification and blocking an unknown-balance reduction are implementation-contract safeguards, not independently stated client accounting policy. Receiving UI remains deferred.

Source: SERVER-WORKFLOW (checkReceivedFloor; recordReceipt) · CONTRACT-0924 (Delta CR and received-floor contract)

No invented receipt balance

The unexplained $3,000 in the demonstration is not verified receiving evidence.

Applies to

Money, budgets, taxes and credits

How to check

Human confirmation required. Trace any displayed receipt floor to its source and do not install $3,000 as a default.

Note: Human verification required for historical balances. Removing the invented value does not authorize removing the real received-value safeguard.

Source: CALL-0924 (00:03:28-00:03:49) · RECON-0924 (F14 receiving)

Authoritative tax snapshots

The shared service establishes rates from trusted configuration for new lines and preserves trusted historical snapshots; requester-supplied rates cannot reduce approval routing.

Applies to

Money, budgets, taxes and credits

How to check

Try forged zero rates on a configured taxable purchase, then edit/reorder saved lines and verify legitimate historical rates survive.

Source: CONTRACT-0924 (Tax integrity update) · TEST-SERVER (new tax snapshots reject requester rate forgery on create, save, append, project change and correction)

Project then PO

Choose the project before choosing the existing PO, and offer only POs for that project.

Applies to

Change requests, corrections and history

How to check

Select a project and verify the PO list is scoped; changing project clears an incompatible PO.

Source: CALL-0923 (00:05:17-00:06:26)

Blank change lines

A new CR starts with blank change lines and retains the original approved PO lines separately.

Applies to

Change requests, corrections and history

How to check

Add two CR lines to a three-line PO and verify the issued result retains all five lines.

Note: This supersedes the earlier editable-baseline intake. Do not replace the full PO with only the delta.

Source: CALL-0924 (00:11:29-00:12:38)

Inherited header and requirements

CR inherits the original vendor, recipient, header and requirements; hide redundant deliverables and contract controls.

Applies to

Change requests, corrections and history

How to check

Open a CR and verify known PO values remain inherited while new change lines are empty.

Source: CALL-0924 (00:05:59-00:06:10; 00:11:29-00:12:24)

Original payment terms

CR users do not reselect payment terms; retain the original terms on the revised PDF.

Applies to

Change requests, corrections and history

How to check

Create a CR and compare resulting payment terms with the original PO.

Source: CALL-0923 (00:06:27-00:07:06)

Change amount routes approval

Route each CR on that change amount, not the revised full PO total or accumulated previous changes.

Applies to

Change requests, corrections and history

How to check

A $10,000 increase to a $45,000 PO uses $10,000 as the change approval basis.

Source: CALL-0916 (00:01:46-00:02:26) · EMAIL-0916 (Reply 3)

Credit approval magnitude convention

Current code routes decreases using the absolute signed change amount.

Applies to

Change requests, corrections and history

How to check

Verify a negative delta produces a positive routing magnitude, while documenting this as implementation pending finance-policy confirmation.

Note: The client confirmed routing per change and supplied valid credits, but did not explicitly define absolute-value routing for every decrease scenario.

Source: SERVER-WORKFLOW (submit, row.routingAmount assignment; routeFor) · APP-CURRENT (changeSummary) · PLAN-0916 (Genuine follow-ups and dependencies)

Quote for ordinary changes

Ordinary new CRs require the supporting quote.

Applies to

Change requests, corrections and history

How to check

Attempt an ordinary new CR without a quote and then with an uploaded quote.

Note: After-the-fact requests have separate reduced-document requirements. A configurable implementation toggle is not proof of a client-approved general waiver.

Source: CALL-0924 (00:12:17-00:12:38)

History remains intact

Retain original approved records and an audit history of changes instead of silently rewriting the original transaction.

Applies to

Change requests, corrections and history

How to check

Compare original and revised records and verify actor, action and saved versions are traceable.

Source: CALL-0910 (00:10:47-00:11:51) · CALL-0924 (00:07:44-00:08:38)

Procurement correction discretion

Authorized Procurement superusers can make minor corrections while preserving approval, or deliberately return a substantial correction for approval.

Applies to

Change requests, corrections and history

How to check

Exercise both correction choices and verify the selected action persists with history.

Note: No fixed monetary tolerance was agreed. The $1 example is not a policy allowing every change under that amount to bypass review.

Source: CALL-0916 (00:05:19-00:07:41) · CALL-0924 (00:08:43-00:09:48)

Stale revisions and correction safety

Current implementation rejects stale PO baselines, rechecks receipt floors at final approval and prevents a corrected delta from being appended twice.

Applies to

Change requests, corrections and history

How to check

Use competing CRs and a full-ledger correction; verify stale submission fails and the combined ledger is not duplicated.

Source: CONTRACT-0924 (Final clarifications; Frontend coordination alignment) · TEST-SERVER (delta corrections do not append the original delta twice and stale CRs cannot issue)

Legacy CR compatibility

Existing replacement-style CRs keep their original meaning while new delta CRs append changes.

Applies to

Change requests, corrections and history

How to check

Load a historical replacement CR and a new delta CR and verify neither is interpreted as the other.

Source: CONTRACT-0924 (New additive CRs and absent changeMode) · TEST-SERVER (legacy replacement CRs stay replacements and require no new quote)

Four-field intake

Initial ER requires project, vendor, emergency reason and approximate spend, then goes directly to review without line items or taxes.

Applies to

Emergency requests

How to check

Complete a fresh ER with those four fields and no priced lines, quote, site instructions or taxes.

Note: Supersedes the earlier vendor/reason-only discussion and the September 22 optional-line flow.

Source: CALL-0923 (00:12:46-00:15:59; 00:19:05-00:19:19)

Immediate emergency number

Issue an emergency PO reference without waiting for ordinary financial approvals so the requester can contact the vendor.

Applies to

Emergency requests

How to check

Submit a minimal ER and verify a clearly identified number is available immediately.

Note: The client requested immediate emergency numbering. Later user direction shows the provisional number only after successful ER submission, prominently on confirmation. This does not mean the purchase is fully approved or completed.

Source: CALL-0910 (00:20:00-00:21:17) · PROJECT-NOTES (Key Decisions, September 19 provisional PO display instruction)

Retain emergency and follow up

Keep the emergency record and follow up for actual scope and costs, normally the next day. Do not automatically discard it because details are incomplete.

Applies to

Emergency requests

How to check

Reopen an ER and collect full details with its original history intact.

Source: CALL-0916 (00:12:22-00:15:14) · CALL-0923 (00:13:48-00:15:51)

Visible emergency reference

Show the emergency PO number in the requisition list as well as details, with a path to complete purchase information.

Applies to

Emergency requests

How to check

Compare the ER list, detail and follow-up action for the same reference.

Source: CALL-0929 (00:10:17-00:11:44)

Same-number retention convention

Current implementation retains the reserved emergency number through detailed completion and later approval.

Applies to

Emergency requests

How to check

Complete an ER and verify the reservation is reused rather than generating a second PO.

Note: Consistent with operational follow-up, but early calls did not separately ratify a provisional-to-permanent numbering policy.

Source: TEST-FRONTEND (previously recorded emergency remains resumable without changing its number) · SERVER-STORE (nextPoNumber) · AUDIT-QUESTIONS (Row 10)

Exceptional emergency outcomes

No detailed new abandonment, cancellation or rejection-after-vendor-use branch was agreed beyond retaining the record and following up.

Applies to

Emergency requests

How to check

Human confirmation required before adding automatic deletion, cancellation, number recycling or special emergency escalation.

Source: CALL-0916 (00:12:22-00:15:14)

PR and CR after-the-fact flag

Both PR and CR can be explicitly marked after the fact when work or purchase commitment already happened.

Applies to

After-the-fact purchases

How to check

Create each type with the flag and preserve it in stored records and later reporting.

Source: CALL-0916 (00:47:00-00:49:55) · EMAIL-0916 (PRs and CRs after the fact)

Retain financial essentials

After-the-fact requests retain vendor, project and complete financial lines, including quantities, units, descriptions, cost codes and amounts.

Applies to

After-the-fact purchases

How to check

Verify every financial line is present and validated despite the simplified header.

Source: CALL-0916 (00:50:35-00:51:00)

Hide irrelevant vendor instructions

After-the-fact entry does not require future-delivery instructions, site contacts, PO recipient, supplier quote or special deliverables solely for the vendor.

Applies to

After-the-fact purchases

How to check

Complete an after-the-fact request without those fields while retaining financial requirements.

Note: An invoice may be supplied. Do not reinstate the ordinary CR quote gate indiscriminately on this path.

Source: CALL-0916 (00:51:00-00:51:54)

Procurement decides vendor distribution

An after-the-fact PO need not be sent to the vendor, but accounting needs the information and requester or PM may need a copy for records.

Applies to

After-the-fact purchases

How to check

Verify vendor sending can be omitted without losing the internal accounting and record-copy path.

Source: CALL-0916 (00:08:40-00:12:18) · EMAIL-0916 (Reply 5 and PRs and CRs after the fact)

No invented punitive approvals

After-the-fact management visibility is required, but extra recipients and any special escalation are not fully decided.

Applies to

After-the-fact purchases

How to check

Human confirmation required before adding mandatory owner approval or mass notification solely because the flag is set.

Source: CALL-0916 (00:48:42-00:49:55; 00:51:58-00:52:19)

Simple sourcing intake

SR captures the need, available budget and project without requiring the normal vendor and full purchase form.

Applies to

Sourcing requests and future conversion

How to check

Submit a sourcing need without a chosen vendor or fully priced purchase lines.

Source: CALL-0910 (00:00:55-00:01:23)

No purchase approval for sourcing

SR goes to Procurement without the purchase approval chain and may close without becoming a PO.

Applies to

Sourcing requests and future conversion

How to check

Close an SR without creating a PO or requiring PM financial approval.

Source: CALL-0916 (00:15:16-00:17:26)

Mandatory Need-By

SR requires a Need-By date describing when the requester needs the outcome, distinct from a vendor delivery promise.

Applies to

Sourcing requests and future conversion

How to check

Block SR submission with no Need-By and verify the entered date persists.

Source: EMAIL-0928 (Section 5, Need-By Date) · CALL-0929 (00:21:36-00:21:58)

Requester decides purchase

Completing sourcing must not automatically create a PR. Return findings to the requester, who decides whether and when to purchase.

Applies to

Sourcing requests and future conversion

How to check

Complete sourcing and verify no purchasing commitment is automatically created.

Source: CALL-0929 (00:22:01-00:23:40)

Manual sourcing handoff allowed

Procurement may exchange results and the proceed-or-not decision by email outside the app for initial operation.

Applies to

Sourcing requests and future conversion

How to check

Release instructions explain the manual handoff without claiming an implemented return workflow.

Source: CALL-0929 (00:24:09-00:24:35)

Future results-return interface

Build the detailed sourcing results return and requester-controlled conversion interface later.

Applies to

Sourcing requests and future conversion

How to check

When scoped, verify quotes, drawings and supporting information can be returned and the authorized requester chooses conversion.

Source: CALL-0929 (00:22:26-00:24:35)

Conversion identity and permissions

The earlier preference was to continue the same request and number, but the latest return/conversion interface and precise permission rules remain to be designed.

Applies to

Sourcing requests and future conversion

How to check

Human confirmation required for the final conversion contract; preserve source linkage and do not equate current Procurement-only conversion with approved future permissions.

Source: EMAIL-0916 (Replies 7-8) · CALL-0916 (00:15:19-00:17:26) · CALL-0929 (00:22:01-00:24:35)

Review after business approval

After financial approval, show the PO number and Under Procurement Review while Procurement completes manual Spectrum entry.

Applies to

Procurement review and Spectrum completion

How to check

Submit an in-limit PM purchase and verify its message does not imply completed external entry.

Source: CALL-0924 (00:16:38-00:19:16) · CALL-0929 (00:17:51-00:19:36)

Spectrum-ready marker

Provide a persistent marker showing Procurement has actually entered the approved PO in Spectrum. Future automation may set it after successful transfer.

Applies to

Procurement review and Spectrum completion

How to check

Mark a genuinely entered item and verify state remains visible after reload and to shared users in the actual app.

Note: A manually checked marker is not proof an API performed a transfer.

Source: CALL-0929 (00:05:40-00:08:23)

Pending action queue

Let Procurement filter business-approved requests needing review or Spectrum entry, and distinguish ready from not-ready items while retaining access to other records.

Applies to

Procurement review and Spectrum completion

How to check

Mark entry complete and verify the item leaves the pending Procurement queue.

Source: CALL-0929 (00:05:50-00:10:08)

Completion communication

Communicate to the requester when Procurement completes its work, and keep notification wording editable.

Applies to

Procurement review and Spectrum completion

How to check

Verify the actual completion transition produces the configured requester communication, distinct from financial approval.

Note: Paused at the client's request on October 14, 2026 (EMAIL-1014): the Procurement review complete notice is not queued at launch. The requester still sees Complete and the history entry in Conduit. Re-enabling is a configuration change.

Source: CALL-0929 (00:17:51-00:19:36)

Completion trigger still needs alignment

The exact relationship among Spectrum-ready, final Procurement completion, vendor/accounting dispatch and their notification triggers needs an explicit operational contract.

Applies to

Procurement review and Spectrum completion

How to check

Human confirmation required before treating the mockup combined action as the only approved production trigger.

Source: CALL-0929 (00:17:51-00:19:36) · BACKLOG-0929 (T03; Remaining decisions and dependencies item 3) · AUDIT-0924 (F04)

Manual Spectrum entry first

Manual entry into Spectrum is acceptable for rollout; API integration is a later enhancement.

Applies to

Procurement review and Spectrum completion

How to check

Verify the core request and review workflow can operate without an active Spectrum connector.

Source: CALL-0929 (00:01:02-00:01:44; 00:06:17-00:08:18)

Seven-digit new PO base

New PO base numbers use two year digits followed immediately by five sequence digits, without a hyphen.

Applies to

PO and change-order numbering

How to check

Verify a new 2026 base number matches 26 followed by five digits, such as 2600001.

Note: Supersedes the September 24 spoken 26-00001 example.

Source: CALL-0929 (00:19:37-00:20:39)

Spectrum length limit

Identifiers imported into Spectrum must respect its stated maximum of ten characters.

Applies to

PO and change-order numbering

How to check

Check the actual exported identifier, separately from the human-readable CO label, stays within ten characters.

Note: Ten is the external maximum, not the requested length of the new base number.

Source: CALL-0924 (00:13:21-00:14:43)

Ordinary PO after approval

Ordinary purchases expose their PO number after approval; ER is the explicit immediate-number exception.

Applies to

PO and change-order numbering

How to check

An unapproved PR has a request reference but no usable issued PO number.

Source: CALL-0910 (00:20:00-00:21:17)

Explicit confirmation wording

Identify the confirmation as a PO number rather than displaying an unexplained number alone.

Applies to

PO and change-order numbering

How to check

Confirmation uses wording such as Your PO Number will be 2600001 and matches the record reference.

Source: CALL-0929 (00:19:37-00:20:16) · EMAIL-0928 (Section 3, PO Number Message)

Visible change sequence

Identify each change with a visible sequential CO or revision label linked to the original PO so users recognize the change before opening its PDF. CO is preferred.

Applies to

PO and change-order numbering

How to check

Create two changes on one PO and verify distinct sequence labels with the original PO traceable.

Source: CALL-0929 (00:20:41-00:21:35)

Exact CO format

The precise CO separator, suffix and exported numbering convention is not finalized.

Applies to

PO and change-order numbering

How to check

Human confirmation required before assigning a new external suffix convention or treating a display label as the Spectrum identifier.

Source: CALL-0929 (00:20:41-00:21:35) · BACKLOG-0929 (Remaining decisions and dependencies item 1)

Demo corrections and historical identifiers

Correct confusing built-in mockup PO identifiers and proven saved demo references under the explicit demo-migration authorization. Preserve unrelated imported, historical, ambiguous and shared-service identifiers unless separately authorized for migration.

Applies to

Built-in local mockup and publicly served mockup examples, including positively identified saved browser demo references; not general historical renumbering.

How to check

Verify valve baseline 2600712, rental 2600839 and emergency 2600841 across fresh examples, proven saved references, linked changes, details and printable previews. Verify idempotence, collision refusal, preserved unrelated records and unchanged historical free-text evidence. Verify the published mockup separately after lead integration.

Note: The user explicitly authorized this correction, including local/public examples; no further historical-migration decision is required for proven built-in demos. Preserving suffixes is a demo convention, not general numbering policy. Earlier instructions to retain old seed numbers are superseded. Reported local implementation evidence does not establish finished public deployment.

Source: PO-REVIEW (Final current handoff: consolidated F1–F8 pass; Evidence and scope before edits) · PO-REVIEW (Evidence and scope before edits; Completed fixes; Lead follow-up: legacy draft order and corrected titles; Lead follow-up: local collision guard and shared persistence)

Sequence mechanics

Year rollover, allocator concurrency and exhaustion behavior are technical conventions requiring verification and eventual import acceptance.

Applies to

PO and change-order numbering

How to check

Verify duplicate prevention and rollover in the actual shared allocator; human confirmation required for unagreed business reset/suffix policies.

Note: Shared implementation uses an atomic year-scoped sequence and a 99,999 guard. Browser mockup allocation cannot establish multi-user uniqueness.

Source: AUDIT-0924 (F09) · SERVER-STORE (nextPoNumber)

Quote upload and mobile source

Users with a quote attach it, including uploading a downloaded file or a photo from a phone.

Applies to

Quotes, terms, deliverables and vendor PDFs

How to check

Verify normal quote attachment from desktop and phone; distinguish attachment support from deferred extraction.

Note: Quote yes/no remains in ordinary intake. Ordinary CR requirement and after-the-fact exceptions are separately cataloged.

Source: CALL-0910 (00:04:04-00:04:40; 00:05:47-00:07:26)

Deliberate cost-code choice

Users deliberately select cost codes; automated extraction must not suggest a code that users merely accept without thought.

Applies to

Quotes, terms, deliverables and vendor PDFs

How to check

Inspect extraction/manual entry and verify no automatic cost-code recommendation is presented as authoritative.

Source: CALL-0910 (00:04:40-00:05:05)

Configurable payment terms

Payment-term choices and the default are maintained in Configuration.

Applies to

Quotes, terms, deliverables and vendor PDFs

How to check

Change the default and verify a new PR uses it without rewriting an existing PO or CR terms.

Source: CALL-0923 (00:19:53-00:21:45)

Selectable configurable requirements

Deliverables and contract instructions use selectable choices with appropriate conditional fields, and administrators can maintain the list.

Applies to

Quotes, terms, deliverables and vendor PDFs

How to check

Add a configured choice, select it on a request and verify persistence and document output.

Source: CALL-0916 (00:25:38-00:26:16) · CALL-0923 (00:35:17-00:36:13)

Supplied checklist

Include the supplied bond, startup/commissioning, O&M manual, HSE checklist, CGL insurance, holdback, WCB/equivalent clearance, RFP warranty, progress claim, new-equipment checklist, electronic-copy and hard-copy choices.

Applies to

Quotes, terms, deliverables and vendor PDFs

How to check

Compare available initial choices with the supplied checklist without inventing missing required selections.

Note: Electronic and hard copy are separate supplied options. No final exclusivity rule was specified; do not infer one from an isolated spoken aside.

Source: REF-DELIVERABLES (Supplied deliverables and contract instructions)

Holdback percentage

Holdback is at PO header level. Selecting it reveals a percentage defaulted to 10%, editable for the negotiated amount.

Applies to

Quotes, terms, deliverables and vendor PDFs

How to check

Select holdback, verify 10% appears and can be changed, and confirm it applies at PO level.

Note: This is the client workflow default, not a legal assertion that every purchase must have 10% holdback.

Source: CALL-0923 (00:36:14-00:38:54)

Holdback in approval summary

Show holdback and its percentage in the approver summary.

Applies to

Quotes, terms, deliverables and vendor PDFs

How to check

Approve a request with holdback and verify it is visible without opening every detail.

Source: CALL-0923 (00:38:54-00:39:21)

Current holdback placement

User-directed presentation places holdback first and apart from the configurable deliverables list.

Applies to

Quotes, terms, deliverables and vendor PDFs

How to check

Verify the highlighted holdback section appears above the checklist.

Source: PROJECT-NOTES (September 25 alpha.61 holdback placement note)

Clean vendor PDF

Generate a readable PO from the request data with clearly presented selected requirements, line items, applicable tax percentages and totals.

Applies to

Quotes, terms, deliverables and vendor PDFs

How to check

Render a long multiline PO and inspect selected requirements, numeric alignment, wrapping and pagination.

Source: CALL-0910 (00:12:05-00:12:19) · CALL-0916 (00:20:06-00:22:18) · CALL-0924 (00:19:28-00:20:36)

No internal approval list on vendor copy

Omit internal approval history from the vendor PDF while preserving the internal audit record.

Applies to

Quotes, terms, deliverables and vendor PDFs

How to check

Compare vendor PDF with internal record: no approver listing on the vendor copy, history still available internally.

Note: This supersedes the September 16 example showing approvals on the PDF. Internal notes, change reasons, budget variance explanations and emergency descriptions are internal approval content and do not print on the vendor PDF (DOC-022, decided 2026-10-18).

Source: CALL-0924 (00:20:36-00:20:53) · CALL-0924 (00:08:16-00:08:38)

Remove confusing empty requirements

Vendor PDFs must not show confusing unselected or duplicate requirement placeholders.

Applies to

Quotes, terms, deliverables and vendor PDFs

How to check

Review the output with no selections and with several selections; the vendor can tell what is required.

Note: Earlier None marked / Not Applicable sample labels are historical layout evidence, not a requirement to preserve the confusing September 24 presentation.

Source: CALL-0924 (00:19:28-00:20:09)

Terms appropriate to purchase

Materials and services can use different supplied terms; CCDC is another possible document whose selection criteria remain undecided.

Applies to

Quotes, terms, deliverables and vendor PDFs

How to check

Verify configurable document choices do not automatically assign a generic sample to every purchase.

Source: CALL-0916 (00:39:14-00:41:30)

Category and province terms rules

The intended automatic terms selection uses document category and province together, then combines selected supplied terms with the PO.

Applies to

Quotes, terms, deliverables and vendor PDFs

How to check

When automation is accepted, test two categories and provinces against approved assignments and inspect the complete package.

Note: September 29 explicitly accepts manual attachment for rollout. Category/province direction is settled; actual assignments and precedence are not.

Source: CALL-0929 (00:26:17-00:28:00)

Manual terms attachment

Procurement may download the PO and manually attach applicable terms to the outgoing email during interim operation.

Applies to

Quotes, terms, deliverables and vendor PDFs

How to check

Document this working route rather than claiming incomplete automatic assembly blocks all rollout.

Source: CALL-0929 (00:27:25-00:27:48)

Terms upload and rules usability

Future terms automation must retain uploaded PDFs and make selection rules usable once documents exist, with clear prerequisite or failure messages.

Applies to

Quotes, terms, deliverables and vendor PDFs

How to check

Upload, reload, open rules and inspect the final PDF; confirm actual selected file pages are present.

Source: CALL-0929 (00:26:17-00:27:25; 00:27:49-00:28:00)

Approved legal assignments needed

Actual legal PDFs, category/province assignments, rule precedence and CCDC selection thresholds require approved inputs.

Applies to

Quotes, terms, deliverables and vendor PDFs

How to check

Human confirmation required; never fabricate legal language, assign the reference appendix by default or invent a CCDC threshold.

Source: CALL-0916 (00:40:55-00:41:30) · REF-EMAILS (PO example and terms appendix) · BACKLOG-0929 (Remaining decisions and dependencies item 4)

Purchase categories are reference data

Use the supplied purchase types as configurable reference choices: Subcontractor, Trade (No H/B), Material (Use Supplier T&Cs), Tools/Equipment Rental, Tools/Equipment Purchase and Other.

Applies to

Quotes, terms, deliverables and vendor PDFs

How to check

Compare configured purchase-type choices with the source and keep them distinct from accounting line categories.

Note: Labels alone do not authorize automatic legal-template or holdback assignments.

Source: REF-TAX (Purchase type key)

No copied sample business details

Reference PDF vendor details, signatures, contacts, amounts and invoice instructions must not become defaults for unrelated POs.

Applies to

Quotes, terms, deliverables and vendor PDFs

How to check

Inspect new unrelated PO output and verify values derive from its actual record and approved configuration.

Source: SOURCE-VIDEO (Screenshots; final paragraph) · REF-EMAILS (PO example and terms appendix)

Actual-file quote evidence

Shared new-delta CR validation uses an actual uploaded quote record, not a claimed attachment flag or a filename alone.

Applies to

Quotes, terms, deliverables and vendor PDFs

How to check

Submit with a form-only attachment flag, generic attachment and actual quote; verify only supported quote evidence satisfies the ordinary requirement.

Source: CONTRACT-0924 (Final clarifications) · TEST-SERVER (delta quote proof, immutable original, inherited requirements and additive issue only)

Current legal-package implementation

Shared terms rules use explicitly uploaded file IDs and configured exact-match conditions with unique priorities. Lowest numeric priority wins; no default legal assignments are installed.

Applies to

Quotes, terms, deliverables and vendor PDFs

How to check

Verify matching against deliberately configured files and priorities, and test missing legal input without generating invented terms.

Note: These are technical matching semantics, not client approval of any specific precedence or category/province legal assignment.

Source: CONTRACT-0924 (preferences.termsRules contract) · SERVER-DOCS (matchingTerms)

Address in the PO header

The vendor PO prints the Industra address in white inside the header band, below the logo, as on the client's PO form; the browser PO document matches.

Applies to

Quotes, terms, deliverables and vendor PDFs

How to check

Render a PO and its browser preview; assert the address is white inside the header band below the logo.

Source: CALL-1016 (The address is showing in white font ... Right below industra out there) · REF-PO-V7-3 (Header)

Vendor-facing special instructions

Special instructions on the vendor PO come only from a vendor-facing field that the requester sets and Procurement can correct. Internal notes and approval reasons (change reason, budget variance explanation, emergency description) never print on the PO.

Applies to

Quotes, terms, deliverables and vendor PDFs

How to check

Issue a PO with internal notes, a change reason, a variance explanation and special instructions; assert only the special instructions print.

Note: The box prints on every PO, empty when there is no text, with one bullet per line; that layout follows the client's v7_3 form and is a presentation convention, not a separate client instruction. A project or Configuration default for the field is later work.

Source: CALL-1016 (there is a special box here with the special instructions) · OWNER-1018 (JC-1, JC-3)

Package page count and neutral terms line

Page X of Y on a PO package counts every page, including appended terms pages. The attached-terms line never shows internal values such as the terms kind or the uploaded file name.

Applies to

Quotes, terms, deliverables and vendor PDFs

How to check

Assemble a package with appended terms; assert the page total includes the terms pages and the terms line shows no kind or file name.

Note: Rod accepted either the true count or no count (October 16); the true count was chosen because it keeps the existing footer and tests. The wording of the terms line is neutral coordinator text and may change when the client's reformatted terms arrive.

Source: CALL-1016 (page one of one discussion) · OWNER-1018 (JC-2, JC-3)

Line-level delivery dates

Move requested Delivery Date from the purchase header to individual detailed lines so different items can have different dates.

Applies to

Delivery, need-by and follow-up dates

How to check

Save and reopen mixed-date purchase and change lines and verify each date survives.

Note: Apply at the relevant detailed PR/CR/ER stage. The broad email includes SR, but do not invent priced SR lines or expand minimal ER intake; DATE-006 records the unresolved SR detail.

Source: EMAIL-0928 (Section 1, Header vs. Line Item) · CALL-0929 (00:11:55-00:12:37)

First-line date default

Entering the first line delivery date defaults subsequent lines to that date, while allowing individual overrides.

Applies to

Delivery, need-by and follow-up dates

How to check

Enter one date, add lines, then set a different date on one line.

Source: CALL-0929 (00:12:37-00:13:00)

Line dates on PDF

Show delivery date on each applicable PO line in the generated PDF.

Applies to

Delivery, need-by and follow-up dates

How to check

Render mixed-date and multipage orders and verify each date remains with its own line.

Source: CALL-0929 (00:13:04-00:13:12)

Delivery and Need-By sorting

Provide useful delivery-date and Need-By sorting in the applicable lists, including earliest delivery first for follow-up.

Applies to

Delivery, need-by and follow-up dates

How to check

Exercise ascending and descending sorting with distinct dates and missing dates.

Source: EMAIL-0928 (Section 1, Dashboard & Sorting) · CALL-0924 (00:23:23-00:24:17)

Default propagation and sorting conventions

The mockup updates untouched default-following dates, preserves explicit overrides and clears, and sorts by earliest nonempty line date with unknowns last.

Applies to

Delivery, need-by and follow-up dates

How to check

Verify these exact local conventions, and obtain human confirmation before calling them client-approved edge-case policy.

Source: CONTRACT-0929 (Decision defaults for this mockup) · QA-0929 (T05-T08; Lead-notes continuation)

Sourcing line-date scope

The email requests dates for SR lines, while the call specifies SR Need-By and retains simple need/budget sourcing. The detailed SR line model is unresolved.

Applies to

Delivery, need-by and follow-up dates

How to check

Human confirmation required before adding a compulsory priced-line or vendor-promise stage to sourcing.

Source: EMAIL-0928 (Section 1 and Section 5) · CALL-0929 (00:21:36-00:24:35) · REPORT-0929 (Implemented scope T05-T08)

Vendor-promised follow-up

The follow-up delivery field means the vendor promised delivery date, not the date Procurement contacted the vendor. Future tracking belongs at line level.

Applies to

Delivery, need-by and follow-up dates

How to check

When implemented, retain distinct per-line promises and label them clearly; do not treat a contact date as promised delivery.

Note: Explicitly not a rollout blocker at 00:15:01-00:15:38.

Source: CALL-0929 (00:13:19-00:16:07)

Immediate current-stage notice

Notify the active approver immediately when their stage becomes actionable. Later approvers wait for their turn.

Applies to

Notifications, distribution and acknowledgment

How to check

Submit an above-limit request and verify only the current stage gets an approval notice.

Source: CALL-0916 (00:17:29-00:18:38)

Daily approval reminders

Remind the current approver daily until approval or rejection, then stop or move to the next stage.

Applies to

Notifications, distribution and acknowledgment

How to check

Advance across days and stage transitions; verify reminders stay with the active approver and stop after action.

Note: This later call resolves the September 10 tentative cadence. Exact send hour, business-day calendar and escalation timing are not client-specified.

Source: EMAIL-0916 (Reply 9) · CALL-0916 (00:17:29-00:18:38)

Manual reminder

Procurement can send an immediate reminder containing the current approval link.

Applies to

Notifications, distribution and acknowledgment

How to check

Trigger Remind now and verify the current approver and correct request link.

Note: SMS and clipboard were offered as possibilities, not selected mandatory channels.

Source: CALL-0923 (00:01:19-00:02:23)

Escalation requires a decision

Automatic escalation to other people after delayed approval has no agreed threshold, audience or calendar.

Applies to

Notifications, distribution and acknowledgment

How to check

Human confirmation required before enabling escalation; keep ordinary current-stage daily reminders.

Source: CALL-0910 (00:10:07-00:10:31) · CALL-0916 (00:17:29-00:18:38)

Approval outcome communication

Notify the requester when financial approval completes or the request is rejected, using wording that reflects any remaining Procurement work.

Applies to

Notifications, distribution and acknowledgment

How to check

Verify approval and rejection notifications do not falsely imply Spectrum entry or vendor dispatch.

Note: Paused at the client's request on October 14, 2026 (EMAIL-1014): the Financial approval complete notice is not queued at launch. The rule remains the client's design; re-enabling is a configuration change, not a rule change.

Source: CALL-0916 (00:19:11-00:20:00) · CALL-0924 (00:18:13-00:19:16)

Normal vendor distribution

Normal purchases following the process require a PO to reach the vendor; the preferred automated sender is the system rather than the requester Outlook client.

Applies to

Notifications, distribution and acknowledgment

How to check

Verify normal distribution has a system-send path and vendor recipient; keep readiness timing explicit.

Note: The automated PO package email is paused at the client's request on October 14, 2026 (EMAIL-1014). Until it is re-enabled, Procurement downloads the exact-version package from the Distribution dialog and emails it (DOC-014). The rule text stays the intended design.

Source: CALL-0916 (00:08:04-00:08:37) · CALL-0923 (00:46:16-00:47:51)

Downloadable document link

The intended automated PO email contains a link to the downloadable PDF package rather than a PDF attachment.

Applies to

Notifications, distribution and acknowledgment

How to check

Inspect generated automated email and follow its package link.

Note: September 29 permits manual email attachment of terms as an interim process. Do not confuse that exception with automatic message design. The automated PO package email is paused at the client's request on October 14, 2026 (EMAIL-1014). Until it is re-enabled, Procurement downloads the exact-version package from the Distribution dialog and emails it (DOC-014). The rule text stays the intended design.

Source: CALL-0923 (00:46:56-00:47:12)

Configurable internal copies

Support configured requester, PM, accounting and relevant site-superintendent copies without hardcoding personal recipients.

Applies to

Notifications, distribution and acknowledgment

How to check

Review actual recipient settings and ensure the agreed internal audience receives the appropriate PO information.

Source: CALL-0916 (00:09:14-00:12:18) · CALL-0923 (00:45:19-00:45:42)

Retain actual PO email evidence

Copy vendor PO emails to a designated evidence mailbox so Procurement can later forward the actual email and demonstrate date and recipient.

Applies to

Notifications, distribution and acknowledgment

How to check

Verify the mailbox receives the actual message, not merely an application sent-status entry.

Source: CALL-0924 (00:32:01-00:32:43)

Sender and mailbox inputs

Production sender, evidence mailbox, exact copy mechanism and final message wording require configuration and client input.

Applies to

Notifications, distribution and acknowledgment

How to check

Human confirmation required for missing setup; do not invent a mailbox or treat mockup recipients as approved.

Source: CALL-0923 (00:46:47-00:49:36) · CALL-0924 (00:32:07-00:32:43) · CALL-0929 (00:19:10-00:19:36)

Record vendor acknowledgment

Procurement can record that the vendor acknowledged receiving the PO, and that state persists and appears in PO results.

Applies to

Notifications, distribution and acknowledgment

How to check

Mark acknowledgment, save, navigate away and reload; verify the list and detail agree.

Note: This is receipt of the PO document, not receipt of goods or proof of email delivery.

Source: CALL-0923 (00:51:01-00:51:49) · CALL-0924 (00:22:02-00:23:00)

Optional acknowledgment reference

Current implementation permits acknowledgment without a sales-order reference or note, while auditing changes.

Applies to

Notifications, distribution and acknowledgment

How to check

Save the checkbox alone and then with a note; both persist.

Note: A reference is useful, but the calls did not require one on every acknowledgment.

Source: CONTRACT-0924 (Frontend coordination alignment) · CALL-0929 (00:14:13-00:14:21)

Truthful delivery states

Test outbox, queued, provider accepted, delivered and vendor acknowledged are distinct states; do not label simulated or accepted mail as delivered.

Applies to

Notifications, distribution and acknowledgment

How to check

Inspect status wording and ensure test-only records never become live sends automatically.

Source: SERVICES-0918 (Delivered; Explicit pending inputs and limits item 4) · REPORT-0929 (Deliberate boundaries)

Buyout reminder

Remind the PM to update the buyout master log after PO creation; full buyout automation is later work.

Applies to

Notifications, distribution and acknowledgment

How to check

Verify a configured PM reminder exists without claiming Conduit already maintains the authoritative buyout log.

Note: Paused at the client's request on October 14, 2026 (EMAIL-1014): the buyout log reminder is not queued at launch. Re-enabling is a configuration change.

Source: CALL-0910 (00:15:26-00:16:48)

Editable notification workflows

User-directed notification configuration supports per-type triggers, recipients, delays, repeat loops, maximum messages and editable subject/body.

Applies to

Notifications, distribution and acknowledgment

How to check

Verify configuration persists and previews do not send mail.

Note: Client immediate/daily defaults remain the baseline. Custom example schedules are tests, not additional client-approved policy. Notification navigation may be hidden in the mockup.

Source: PROJECT-NOTES (Key Decisions, September 19 campaign-style notifications) · NOTIFY-CONTRACT (Capabilities and boundaries)

Unagreed follow-up defaults stay paused

Current SR and emergency-details follow-up templates start paused because automated audience and timing were not agreed.

Applies to

Notifications, distribution and acknowledgment

How to check

Verify a fresh configuration does not silently send these follow-ups.

Source: NOTIFY-CONTRACT (Source basis and editable defaults)

Scheduler timing and deduplication

Current scheduler uses Vancouver calendar days, suppresses duplicate stage/day reminders, cancels stale-stage work and does not backfill the historical archive when templates are saved.

Applies to

Notifications, distribution and acknowledgment

How to check

Test repeated runs, stage change, restart and local midnight without duplicate bursts.

Note: Timezone and scheduler semantics are implementation conventions. The client required daily reminders, not an exact send second.

Source: NOTIFY-CONTRACT (Capabilities and boundaries)

Maintained master imports

Provide templates and maintained imports for projects, vendors and cost codes so initial operation does not depend on an API.

Applies to

Projects, vendors, cost codes and configuration

How to check

Import each master type, update an existing record and verify the updated choice is available.

Source: CALL-0916 (00:27:09-00:31:08) · CALL-0924 (00:25:12-00:25:57)

Project-specific cost codes

Cost-code imports and selection preserve project association; the same code across projects must not be conflated.

Applies to

Projects, vendors, cost codes and configuration

How to check

Import the same code for two projects and verify each project gets its own record.

Source: CALL-0923 (01:09:28-01:11:16)

Meaningful import mapping

Recognize supplied cost-code export headings and reduce excessive manual mapping to meaningful fields needing review.

Applies to

Projects, vendors, cost codes and configuration

How to check

Use the actual customer export when available; verify meaningful columns map and empty padding does not create mapping work.

Note: Empty file padding was a suspected cause, not an established diagnosis. Padding handling is a tested implementation fix for representative fixtures; exact customer cost-code CSV reproduction remains pending because the available source is a screenshot.

Source: EMAIL-0928 (Section 7) · CALL-0929 (00:28:01-00:28:55)

Partial merge implementation

Current imports update matching records and add new ones, preserve omitted records and unmapped fields, and clear fields only when explicitly supplied blank.

Applies to

Projects, vendors, cost codes and configuration

How to check

Test repeat import, partial columns and explicit blank separately.

Source: REF-IMPORT (Partial imports paragraph) · TEST-FRONTEND (September 25: vendor partial uploads retain omitted records and fields, including source metadata)

Import identity requires confirmation

Vendor Code and Project Number are used for matching; Project # plus Full Reference is a provisional cost-code identity, not confirmed uniqueness policy.

Applies to

Projects, vendors, cost codes and configuration

How to check

Human confirmation required before treating provisional identity or unknown status vocabulary as authoritative master-data rules.

Source: REF-IMPORT (Frontend alpha.60 mapping paragraph)

Source financial columns are not budgets

Imported cost budget/quantity and project contract columns are preserved as reference metadata; they do not automatically become requisition budgets.

Applies to

Projects, vendors, cost codes and configuration

How to check

Import those columns and verify no unapproved financial calculation or available-balance claim is created.

Source: REF-IMPORT (Partial imports paragraph)

Active projects for intake

Projects can be active or inactive, and new request selection offers active projects.

Applies to

Projects, vendors, cost codes and configuration

How to check

Inactivate a project and verify it disappears from new-request selection.

Source: CALL-0924 (00:26:01-00:26:53)

Preserve inactive history

Current implementation retains historical records and pending approvals when a project becomes inactive.

Applies to

Projects, vendors, cost codes and configuration

How to check

Inactivate a project with an existing PO and pending request; verify historical reads and existing approval remain available.

Note: Preservation follows the history requirement; whether new CRs against inactive-project POs need an exception remains open.

Source: CONTRACT-0924 (project.active contract) · RECON-0924 (Additional acceptance boundaries)

Inactive-project change exception

No explicit business exception permits new CRs for an inactive project.

Applies to

Projects, vendors, cost codes and configuration

How to check

Human confirmation required before creating such an exception; current active-only intake blocks it.

Source: RECON-0924 (Additional acceptance boundaries) · CALL-0924 (00:26:16-00:26:53)

Missing project and cost masters block purchase

A missing vendor may proceed through setup, but missing required project or cost-code masters must be created before proceeding with the purchase.

Applies to

Projects, vendors, cost codes and configuration

How to check

Verify a vendor setup request can progress while missing project/cost-code selection cannot be silently fabricated.

Note: Minimal SR/ER intake has its own reduced requirements; full accounting lines are collected at the appropriate purchase-detail stage.

Source: CALL-0910 (00:08:32-00:10:07)

Nonblocking vendor setup request

When the vendor is absent, offer a new-vendor request to accounting without holding up the PO solely for vendor-master creation.

Applies to

Projects, vendors, cost codes and configuration

How to check

Capture a new vendor, verify an actual accounting handoff, and allow the PO workflow to proceed.

Note: A saved vendorRequest flag alone does not prove the requested accounting handoff happened. Spectrum registration still depends on accounting setup.

Source: CALL-0910 (00:08:32-00:09:37)

Vendor minimum data

New-vendor setup captures legal name, operating name if applicable, address, contact, phone, email and business/tax number. EFT or payment-method paperwork must not delay the initial request.

Applies to

Projects, vendors, cost codes and configuration

How to check

Verify minimum fields and an optional payment-setup route, without requiring all EFT fields.

Source: EMAIL-0916 (Reply 11) · CALL-0916 (00:22:24-00:24:00)

Assigned-project default with coverage

Show assigned projects by default with a way to view other projects for coverage, without borrowing their assigned approvers authority.

Applies to

Projects, vendors, cost codes and configuration

How to check

A covering user can find the other project and initiate work, while approvals still follow that project assignments.

Source: CALL-0916 (00:32:12-00:33:33)

Project instructions

Store reusable delivery/site/contact instructions on the project and prepopulate requests for that project, with request-level editing available.

Applies to

Projects, vendors, cost codes and configuration

How to check

Create two requests for the same project and verify consistent defaults; edit one without altering the other.

Source: CALL-0916 (00:41:35-00:44:32)

Unresolved source data

Missing or conflicting project numbers, province associations and approval people must remain unresolved until verified rather than inferred from unrelated records.

Applies to

Projects, vendors, cost codes and configuration

How to check

Verify incomplete imported records are flagged and cannot silently authorize a purchase.

Source: REF-PROJECTS (Source issues preserved for internal review; Version-one implementation) · PLAN-0916 (Initial master data and Project assignments; step 4) · REPORT-0929 (Implemented scope T09)

Editable units and categories

User-directed units and line categories are configurable dropdowns. Changing options preserves saved line values.

Applies to

Projects, vendors, cost codes and configuration

How to check

Edit each list and verify new-line choices update while existing saved values remain.

Note: Original app Category was free text. Initial implementation choices are not a client-mandated exhaustive vocabulary or automatic purchase-type mapping.

Source: PROJECT-NOTES (Key Decisions, September 19 Unit and Category dropdowns)

Ordinary and Procurement queues

Ordinary users see their own relevant requests and approvals; Procurement can inspect queues by requester and approver to find bottlenecks.

Applies to

Visibility, access and integrity

How to check

Compare ordinary-user and Procurement views and verify filters do not expose unauthorized records.

Source: CALL-0923 (00:02:30-00:03:55)

Restricted future management reports

Future management metrics and suspected split-change views are restricted to the agreed Procurement/management audience, not everyone.

Applies to

Visibility, access and integrity

How to check

When reports are enabled, verify unauthorized users cannot access them; human confirmation required for the final expanded role list.

Source: CALL-0916 (00:02:31-00:05:13) · CALL-0924 (00:34:10-00:34:55)

Server enforces authority

Shared implementation authenticates users and checks permissions, current approval actor and CSRF on the server; hiding UI controls is insufficient.

Applies to

Visibility, access and integrity

How to check

Attempt direct unauthorized approval, correction, file and configuration requests and verify rejection.

Source: SERVICES-0918 (Delivered; Verification) · SERVER-WORKFLOW (access; actionRequest; routeFor)

Stable submitted routes

Current implementation snapshots submitted routes and rejects conflicting saves rather than silently applying changed configuration or overwriting another user.

Applies to

Visibility, access and integrity

How to check

Change configuration after submission and simulate competing edits; verify route stability and explicit conflict response.

Source: SERVICES-0918 (Delivered) · TEST-FRONTEND (shared 409 preserves typed draft and does not silently retry with latest version)

No invisible switch to examples

If a shared session fails, current UI keeps a reconnect state instead of substituting browser demo data as if it were the shared workspace.

Applies to

Visibility, access and integrity

How to check

Expire a shared session and verify the user sees the connection problem without fabricated shared records.

Source: TEST-FRONTEND (remembered shared mode gates examples on startup and stays reconnect-only when unavailable)

Production privilege setup

Provision real accounts and privileged roles through controlled setup; editable directory titles alone do not grant admin or Procurement powers.

Applies to

Visibility, access and integrity

How to check

Change a directory title and verify privileged capability does not change.

Source: SERVICES-0918 (Delivered; Explicit pending inputs and limits)

Mobile core workflows

Request creation and approval work on phones; specialized superuser functions may remain desktop-focused.

Applies to

Navigation, mobile and usable records

How to check

Complete core request and approval scenarios at phone widths with usable controls.

Source: CALL-0910 (00:37:19-00:38:31)

Home-screen web app

Provide app-like home-screen launch and instructions without requiring an app-store download.

Applies to

Navigation, mobile and usable records

How to check

Verify installation instructions and standalone launch on an actual supported phone.

Note: No offline, native-store app or push-notification requirement was agreed.

Source: CALL-0924 (00:35:00-00:35:47)

Prominent requisition number

Make requisition number the primary bold identifier, with description secondary.

Applies to

Navigation, mobile and usable records

How to check

Inspect requisition lists and confirm number-first presentation.

Source: CALL-0923 (00:04:00-00:04:30)

Search and results before detail

Provide PO navigation with search results leading to a condensed PO detail view, with full header and view/print access.

Applies to

Navigation, mobile and usable records

How to check

Find a PO, open its line snapshot and access remaining header details and preview.

Note: The richer vendor/job/requester search discussion allows reduced initial scope. Do not require every exploratory spreadsheet filter as a release gate.

Source: CALL-0923 (00:52:34-00:58:34; 00:59:41-01:02:46)

Compact PO rows

Show one compact row per PO including number, vendor, project, amount, creation date and relevant delivery information.

Applies to

Navigation, mobile and usable records

How to check

Inspect multiple POs and verify creation date is visible rather than inferred from numbering.

Source: CALL-0924 (00:23:02-00:24:24)

Filters and sorting

Support awaiting-vendor-acknowledgment filtering and useful project/date sorting in PO and request views.

Applies to

Navigation, mobile and usable records

How to check

Filter acknowledged versus awaiting records and sort by the stated fields.

Source: CALL-0924 (00:23:36-00:24:17)

Related-record links

Related PO and requisition numbers open the corresponding record directly.

Applies to

Navigation, mobile and usable records

How to check

Navigate from request to PO and back without repeating a search.

Source: CALL-0924 (00:24:24-00:25:01)

Clear rule errors

Validation identifies the rule that caused the error and points authorized users to its configuration or explanation.

Applies to

Navigation, mobile and usable records

How to check

Trigger a rule error and verify understandable cause and a usable Configuration pointer.

Note: The call does not authorize arbitrary disabling of every safeguard or a general rules programming language.

Source: CALL-0924 (00:04:05-00:05:26)

Easy dialog dismissal

Allow clicking outside the discussed detail dialog to close it where straightforward.

Applies to

Navigation, mobile and usable records

How to check

Verify outside-click close works and existing unsaved-edit protection remains.

Source: CALL-0923 (00:42:51-00:43:22)

Conduit branding

Use Conduit branding; where the tagline appears its order is Procure, Build, Achieve. Avoid repeated name/tagline text beside the logo.

Applies to

Navigation, mobile and usable records

How to check

Inspect navigation branding for the supplied logo and no duplicate adjacent wording.

Source: CALL-0923 (01:03:19-01:04:55) · CALL-0924 (00:27:02-00:27:11)

Accounting spreadsheet fields need mapping

Separate G/L Account, Phase and other spreadsheet-only columns are reference evidence, not proof of approved field mappings or immediate scope.

Applies to

Navigation, mobile and usable records

How to check

Human confirmation required before treating cost code as equivalent to G/L or Phase.

Source: REF-SHEET (Spreadsheet transcription; Comparison with alpha.41)

In-app confirmations

Use in-app confirmations with explicit action and Cancel controls rather than browser alert, confirm or prompt dialogs.

Applies to

Navigation, mobile and usable records

How to check

Exercise deletion, PO switching and unsaved navigation; verify keyboard Escape and cancellation preserve data.

Source: PROJECT-NOTES (Key Decisions, September 19 app-wide confirmation requirement)

Hide only genuinely empty fields

The Hide empty fields preference hides blank detail rows but retains meaningful zero amounts and No values without losing reviewer notes.

Applies to

Navigation, mobile and usable records

How to check

Toggle it on a request containing blanks, zero and No, and verify only blanks disappear.

Source: PROJECT-NOTES (September 15 Hide empty fields update) · LAYOUT-PLAN (Request review, details and approvals)

Readable responsive controls

Size fields to their content, preserve full long values, logical keyboard order, visible focus and usable touch controls. Avoid page-wide overflow while allowing deliberate table scrolling.

Applies to

Navigation, mobile and usable records

How to check

Check long values and validation at 320, 390, 768, 1024, 1440 and 1920 pixels and relevant zoom.

Source: LAYOUT-PLAN (Sizing rules; Implementation order and acceptance checks)

Spectrum writeback

Future integration should remove duplicate entry of project number, tax data and line items into Spectrum, while vendor-facing deliverables remain on the PDF.

Applies to

Deferred integration, AI, receiving and reporting

How to check

When scoped, compare the verified finance mapping and confirm transfer success before marking ready.

Source: CALL-0910 (00:17:00-00:18:06) · CALL-0929 (00:06:17-00:08:18)

Finance-system access and mappings

Spectrum access, API documentation, tax examples and any later Procore migration require Finance coordination and verified mappings.

Applies to

Deferred integration, AI, receiving and reporting

How to check

Human confirmation required for integration inputs; do not claim either system is connected from import screens alone.

Source: CALL-0916 (00:24:13-00:25:05; 00:55:55-00:56:10) · EMAIL-0916 (AI Questions)

Human-reviewed extraction

Future quote/invoice/photo extraction proposes values for human review before applying them and preserves deliberate cost-code selection.

Applies to

Deferred integration, AI, receiving and reporting

How to check

Use varied real source formats and verify a human can compare, edit and confirm before application.

Source: CALL-0916 (00:53:14-00:55:50) · CALL-0923 (00:39:36-00:42:44)

Stack AI coordination

Coordinate future document-to-form extraction with the client Stack AI initiative rather than assuming a new extraction deployment or access grant.

Applies to

Deferred integration, AI, receiving and reporting

How to check

Await the actual agent design and explicit interface/access requirements.

Source: CALL-0929 (00:29:00-00:30:30)

Guided sourcing assistance

Future internal sourcing assistance may prompt for missing quantity, size, material, duration or scope without requiring staff personal AI subscriptions.

Applies to

Deferred integration, AI, receiving and reporting

How to check

When scoped, test incomplete sourcing descriptions and distinguish real AI from deterministic prompts.

Source: CALL-0916 (00:56:13-00:59:07) · COVERAGE-0919 (Covered in the implementation: September 19 AI deferral)

Receiving later

Defer receiving-entry UI. Future receiving must support different lines, receivers and dates, not only a single PO amount.

Applies to

Deferred integration, AI, receiving and reporting

How to check

Do not require the receiving UI for current rollout; future tests must cover partial line receipts and different receivers/dates.

Note: This does not remove the confirmed received-value floor or erase verified existing receipts.

Source: CALL-0923 (00:49:37-00:51:01)

Management KPIs later

Defer dashboards/KPIs independently of initial release. Candidate metrics include after-the-fact volume, requests per user, login usage, acknowledgment time and on-time delivery.

Applies to

Deferred integration, AI, receiving and reporting

How to check

Keep current release gates separate; obtain the final metric definitions and real source data before reporting performance.

Source: CALL-0924 (00:32:52-00:34:55)

Activity and bottleneck evidence

Retain timestamps and activity needed to measure procurement output, change-order work and time spent at each approval stage.

Applies to

Deferred integration, AI, receiving and reporting

How to check

Verify both new POs and changes create traceable activity; later reporting must not count only PO creation.

Note: Data capture supports later reporting; no fixed bottleneck threshold was specified.

Source: CALL-0910 (00:22:00-00:23:44)

Potential split-change review

Future restricted reports help Procurement inspect repeated changes near approval limits without changing per-change routing or automatically accusing users.

Applies to

Deferred integration, AI, receiving and reporting

How to check

When enabled, show source requests and transparent criteria; no automatic misconduct verdict or extra approval stage.

Note: The reporting direction is retained, but visible Review policy/reporting was removed from immediate scope.

Source: CALL-0916 (00:02:26-00:05:13) · CALL-0923 (00:10:49-00:12:11)

Buyout automation later

Automatic buyout-log calculation is a later operational enhancement, beyond the initial reminder.

Applies to

Deferred integration, AI, receiving and reporting

How to check

Do not claim an automatically maintained buyout ledger from the reminder setting alone.

Source: CALL-0910 (00:15:26-00:16:48)

Separate adjacent AI ideas

Tender monitoring, policy Q&A and autonomous better-quote sourcing were future or separately scoped ideas, not current Conduit release requirements.

Applies to

Deferred integration, AI, receiving and reporting

How to check

Do not add them as current release gates or claim they are delivered.

Note: Tender monitoring explicitly belongs to another group and requires its own decision.

Source: CALL-0910 (00:24:53-00:33:52; 00:36:29-00:37:18)

Actual workflow testing

Test ordinary workflows, reported failures and relevant edge cases before inviting the client team, and provide recorded workflow evidence.

Applies to

Release acceptance and operational evidence

How to check

Review actual-app PR/CR/SR/ER, approvals, corrections, uploads/imports and notification test outcomes and videos.

Source: CALL-0910 (00:46:08-00:47:22) · CALL-0929 (00:03:18-00:05:39)

Multi-user sandbox acceptance

Use a test project and distinct role identities to verify sequential approvals and controlled test notification delivery before company rollout.

Applies to

Release acceptance and operational evidence

How to check

Run the group scenario with participants confirming who receives what, including actual controlled test inboxes.

Note: Test targets discussed in calls are not evidence of readiness. Mocked outbox tests do not satisfy actual inbox delivery.

Source: CALL-0924 (00:28:00-00:31:43; 00:35:51-00:36:21) · CALL-0929 (00:01:44-00:02:39)

End-user SOP and training

Provide a user-level SOP and training material after workflows stabilize, aligned with the company procurement policy requiring Conduit.

Applies to

Release acceptance and operational evidence

How to check

Check that ordinary staff can follow PR/CR/SR/ER and approval instructions, not only admin setup notes.

Source: CALL-0924 (00:36:23-00:37:21)

Mockup versus shared state

Alpha.63 Spectrum completion and requester notice are browser-local; shared Spectrum support, server line-date PDFs and actual completion notifications are not established by that release.

Applies to

Release acceptance and operational evidence

How to check

Verify local and shared modes separately and do not mark shared acceptance passed from local UI evidence.

Source: REPORT-0929 (Deliberate boundaries) · QA-0929 (Test status and boundaries)

Known numbering parity gap

Current shared server still generates YY-NNNNN, while the alpha.63 browser mockup generates YYNNNNN.

Applies to

Release acceptance and operational evidence

How to check

Check both allocators; shared new numbering fails NUM-001 until corrected.

Note: This is an observed source-code difference, not authorization to modify the application in this research task.

Source: SERVER-STORE (Store.nextPoNumber) · APP-CURRENT (nextPoNumber)

Recorded QA limits

Alpha.63 reports 138 passing tests and local browser/print QA, but does not establish exact customer cost-code CSV reproduction, multi-user acceptance or live Spectrum writes.

Applies to

Release acceptance and operational evidence

How to check

Read the recorded evidence and preserve its stated test boundaries in release reporting.

Note: This researcher inspected tests and reports but did not rerun application tests for the catalog-only change.

Source: REPORT-0929 (Validation; Deliberate boundaries) · QA-0929 (Test status and boundaries)

Implementation cannot define policy

Old Power App, Power Automate and current code are evidence of behavior, not authority to override later explicit client requirements.

Applies to

Release acceptance and operational evidence

How to check

When code disagrees with a confirmed rule, report the mismatch rather than changing the rule to match code.

Note: Old director-author shortcuts and PM routes differ from the later agreed project-based PM/PD/DM/executive sequence.

Source: FLOW-OLD (Confirmed behavior) · CALL-0916 (00:00:08-00:00:35) · CALL-0923 (00:08:07-00:09:35)

Status-aware future checking

A confirmed row records a requirement, not successful implementation. Open rows require human decisions; deferred rows are future scope; implementation rows document behavior or conventions.

Applies to

Release acceptance and operational evidence

How to check

The future checker must report these categories separately and never automatically fail release on all deferred/open rows.

Source: BACKLOG-0929 (Explicitly deferrable work and interim operation; Remaining decisions and dependencies) · REPORT-0929 (Deliberate boundaries)

Visible version history

Each completed mockup update increments the alpha version and adds a history entry; retrospective history stays labeled as retrospective.

Applies to

Release acceptance and operational evidence

How to check

Compare app footer, asset version references and history for the released update.

Source: PROJECT-NOTES (Key Decisions, September 22 alpha-versioning instruction)

Correct confusing demos without inventing operational facts

Review all confusing built-in PO/request examples and correct demonstrated inconsistencies using verified fixture provenance and configuration. Clearly label illustrative states and missing inputs rather than presenting them as actual approvals, receipts or complete business records.

Applies to

Authorized adversarial review of local and public mockup examples, including safe migration of proven saved demo state.

How to check

Review route recipients, date sorting, project delivery/contact/coding, Procurement state, emergency completion, province taxes, approval/audit presentation and sourcing confirmation. Check deterministic fixes preserve explicit saved values and recorded edits, unsupported values remain visibly unspecified, and public examples are verified after publication. Do not treat a legacy replacement-style CR with missing quote as a complete current additive-CR example.

Note: This is an authorized implementation-quality requirement, not new client accounting policy. The teammate reports deterministic local fixes and 94 passing workflow tests, with inputs still unresolved. Actual delivery/contact data, province configuration, cost allocations, rental unit/category and original emergency intake values must not be invented. Reported tests do not establish public deployment; illustrative setup history is not actual approval evidence.

Source: PROJECT-NOTES (September 25 alpha.62 sample-date note) · REALISM-0925 (Evidence and standards; Resolved, valid states and uncertainty) · PO-REVIEW (Extended fixture-detail audit: evidence before changes; Extended fixture-detail corrections completed) · PO-REVIEW (Final current handoff: consolidated F1–F8 pass, findings F1-F8, safety boundaries and lead action)

Shared SR Need-By validation gap

Current shared SR submission validates the sourcing need but does not require Need-By, unlike the browser validation.

Applies to

Current local/shared implementation, September 29 source inspection

How to check

Verify the direct shared API enforces SR-003 before claiming end-to-end compliance.

Note: Static source finding, not a fresh runtime reproduction.

Source: SERVER-WORKFLOW (submit, SR branch) · APP-CURRENT (validateCurrentStep)

After-the-fact delta quote mismatch

Current local and shared delta-CR quote gates do not exclude after-the-fact changes, conflicting with the earlier reduced-document exception.

Applies to

Current local/shared implementation, September 29 source inspection

How to check

Test a new after-the-fact delta CR without a quote; do not claim ATF-003 passes based on legacy replacement-CR tests.

Note: Static source finding. Reconcile explicitly with the confirmed exception; do not silently rewrite business policy to match code.

Source: APP-CURRENT (validateCurrentStep, delta CR quote condition) · SERVER-WORKFLOW (submit, isDelta quote condition) · CALL-0916 (00:51:00-00:51:54)