TaskRox Help & User Manual

The QA module has three tabs:

Raising a TR — click New TR. Fill in: - Lot number - Chainage / location - Layer (Subgrade, Sub-base, Base, Pavement, etc.) - Material - Work type (Compaction, Concrete, etc.) - Requested by, requested date

A unique TR number is generated (e.g. TR-042).

Emailing the technician — click Send to technician. Enter their email. They receive a one-time link valid for 48 hours to submit their results at /qa/complete/[token] — no login required.

Receiving results — when the technician submits, the TR updates with their results, field data, and any uploaded files (photos, signed hold point sheets, lab PDFs).

Pass / Fail — the QA engineer reviews and clicks Mark Pass or Mark Fail. A failed TR automatically opens a pre-filled NCR creation sheet linked to the TR's lot number and TR ID.

Raising an NCR — click New NCR (or it's auto-opened from a failed TR). Fields: - Description of non-conformance - Lot number - Linked TR (if from a failed test) - Assigned to - Close-out due date - Corrective action required

Close-out — the assignee attaches evidence (photos, signed documents) and clicks Request close-out. The QA manager reviews and clicks Close NCR.

Status workflow — Open → Under Review → Closed.

Creating an ITP — click New ITP (blank, from a template, or as a copy). Add a name and description. A new ITP starts in Draft.

Template library and controlled imports — the Templates button on the ITP tab opens the template library: read-only system templates (several carry curated content imported from real project ITP registers) and your workspace's own project templates. Preview any template's full item table before starting an ITP from it, or duplicate a system template into the project to customise it. QA admins can also revise a project template from a real XLSX or text-based PDF register with Import: the file is parsed deterministically, every added, changed or removed row appears in a structured diff with its source sheet/page, row and verbatim wording, and each change needs an explicit Accept or Reject before the revised version can be published. Scanned PDFs with no machine-readable text are flagged as OCR-required and are never guessed at, and a diff computed against an outdated template version is marked stale rather than silently overwriting newer work.

Header identity — every ITP carries the register header fields from real-world practice: ITP number, revision, client, work area, location, chainage, package number (optional), and discipline. They show in the identity block at the top of the ITP and are edited via Edit details (site-context fields stay editable after approval; document-defining fields lock outside Draft / Revision Requested).

Line items — while the ITP is in Draft (or Revision Requested), add items with: - Description - Type: Hold Point / Witness Point / Review / Document Review - Control level and item kind - Responsible role - Standard / specification reference and test method - Acceptance criteria and required record - Contractor and Principal/Superintendent verification codes - Verification lanes (extra designer/client-QA/other lanes, action, authority label, required count, and permitted witness outcomes) - Measured-result labels - Source reference / acceptance traceability - Frequency - Prerequisites: predecessor item, required condition, and blocking or warning-only mode

Approval workflow — an ITP moves through Draft → Submitted → Approval Pending → Approved → In Progress → Closeout Pending → Closed, with Revision Requested / Superseded / Void branches. Submit the completed plan for approval; the approver can return it for revision. The workflow strip on the ITP shows the current status, who must act next, and the actions available to you.

Formal signatures — approval, configured hold releases, and final closeout use the e-signature envelope flow. Send for approval signature generates a controlled ITP Approval Record; the Contractor Representative signs first and the Superintendent Representative approves (with optional Designer Representative and Client QA slots). When every required signatory has signed, the ITP becomes Approved. A configured hold-point sign-off can generate an ITP Hold Point Release; completion marks the cell Released, while decline marks it Returned. At completion, Send closeout for signature produces the ITP Closeout Certificate the same way; once sealed, the ITP is Closed.

Lots and the sign-off grid — lots open once the ITP is Approved. Use the sign-off grid (rows = items, columns = lots) and click a cell to record an inspection result such as Pass, Fail, Accepted, Rejected, Returned, Not Applicable, NCR Raised, Rework Required, or Closed After Correction. A Hold Point is released only through its authorised verification action or formal release envelope, not the ordinary result list. Template-defined measured values, authority references, notes, and evidence rows sit on the cell. The first sign-off automatically moves an Approved ITP to In Progress. Closeout can only be requested once every lot/item cell has a complete result.

Prerequisites and readiness — while authoring a Draft or Revision Requested ITP, an item can require an earlier item in the same ITP to be completed, accepted, Hold-released, supported by evidence, linked to a passing Test Request or closed NCR, or approved by a named verification party. Rules can block or warn. In the execution grid, each lot is evaluated independently: open Blocked details or Warning details to see the exact unmet condition. Blocking rules prevent new sign-off, verification, Hold release and closeout on the server; warning-only rules stay visible without stopping the action.

The ITP verification model — every ITP item carries a control point and independent verification lanes:

` ITP └── Item ├── activity / inspection / test ├── acceptance criteria + references ├── lot / work area (each lot is verified separately) │ ├── CONTROL POINT — None · Hold · Witness · other │ ├── CONTRACTOR VERIFICATION │ ├── required action + status │ ├── current qualifying sign-off (signer, capacity, signature, date/time) │ └── immutable verification history │ └── PRINCIPAL-SIDE VERIFICATION ├── contract authority title (configurable — Superintendent, Administrator, …) ├── required action (verify · release Hold Point · witness) ├── delegated sign-off where authorised └── immutable verification history `

Control points are not signatures. A Hold Point blocks work from proceeding until the Principal-side authorised person releases it — the release is evidenced by their sign-off, but "Hold" is the item's process constraint, never a signature type. A Witness Point requires the Principal side to attend (or formally record *Attendance waived* / *Notified — did not attend* per the contract); work is not blocked the way a Hold is. An item with no control point can still require Principal-side verification — the two concepts are independent.

Verification lanes (C / P columns) — each item shows the live status of its Contractor and Principal-side lanes: green when every lot is verified, amber when partially verified, red on a rejection, muted while pending. The Principal-side title follows the contract — set it per ITP in Edit details (Superintendent, Administrator, Principal's Representative, Council Representative, …). Item authors can add extra verification lanes on the item sheet for designer, client QA, council, or other roles, including the lane label, authority title, action, signature count, and permitted witness outcomes. Click a C or P cell to open the item's verification lanes per lot. Actions are lane-specific and semantically explicit — *Sign Contractor Verification*, *Verify / Sign Off*, *Release Hold Point*, *Do Not Release*, *Record Witness Outcome* — and each requirement accepts its configured number of signatures, then locks (no duplicate active sign-offs).

Who can sign — the Contractor lane needs QA edit permission. Principal-side actions are limited to authorised project representatives, with access checked before the action is recorded. The signer must have a saved signature mark in Settings → Signature before they can sign an ITP verification, hold release, witness outcome, rejection, or replacement. Delegation is first-class: a CQA or GITA signs as the Principal side, recording their capacity (the role they act in) and on behalf of (whose authority they exercise) — distinct from the contractual party itself.

Signature records and history — every completed verification records who signed, capacity, delegation, outcome, the exact date and time, and the signer's digital mark (the saved e-signature from Settings → Signature). A historical name-only row is shown as Signature missing / Recorded by [name] without signature mark; it stays in the audit trail but does not satisfy a lane, release a Hold Point, or count for closeout. Committed records are never deleted. Corrections use explicit workflows: Replace (supersede) swaps in a new signed record with a mandatory reason, Void (QA admin) retires an erroneous record with a reason, and Reopen Verification (QA admin) returns an accepted cell to pending — all prior records stay visible under *Previous / superseded records* with their lifecycle state (↺ Superseded, ⊘ Void), dates, and reasons.

Connected evidence record — open a C or P cell to review the lot/item's measurements, current evidence, source links, control-point state and verification lanes together. TaskRox record evidence can link to a visible project photo, document, Test Request, NCR or RFI; an immutable source label remains in history if that source is later renamed, archived or no longer visible. External web references are labelled separately. QA editors can Replace evidence with a different visible source and a mandatory reason; QA admins can Void or Restore where the lifecycle permits. Committed evidence is append-only: prior rows remain under *Previous / superseded evidence* with actor, time and reason, while current permission still controls source click-through.

Records and closeout readiness — the Records column links each item's required record to the actual evidence captured on its sign-offs (documents, photos, test reports, external links). Below the sign-off grid, Closeout Readiness shows whether the ITP can be closed out and, when it cannot, exactly why. The check is made on the server over every governed fact at lot x item grain — the inspection result, each required verification lane, Hold Point releases and Witness outcomes, required measured values, unresolved linked NCRs, and blocking prerequisites — so nothing on screen can talk it into passing.

Each outstanding fact is listed with the lot, the item, what the fact is, whether it blocks closeout or is an observation, and what to do about it. Search, sort and filter the list on a large ITP. Observations are recorded but never block: a required record with no evidence attached, or evidence that was superseded and not replaced, is stated so it is visible without stopping a lot that is otherwise complete. A cell marked Not Applicable is an attributed decision that the item does not apply to that lot, and asks nothing further of it.

Closeout packs — once every governed fact is complete, Generate closeout pack produces a controlled dossier for the work package and files it in the project's Generated folder as a PDF. The pack assembles the revision identity, the lots, every item result with its measurements, the evidence index (including superseded and voided evidence as history), the full verification history, a deviations and non-conformance summary, and the signature certificates — with links back to each source record where your permissions allow.

A pack is an immutable record of the facts at the moment it was cut. It is never edited: if the ITP changes and you need a current dossier, generate another and the earlier packs remain as history, each numbered in order. That is deliberate — asked what was certified and on what basis, an ITP can always answer. If the PDF itself fails to render, the dossier is still recorded and Retry PDF produces the document for that same pack rather than certifying afresh. Opening a filed pack PDF needs Documents access; without it the pack still shows as filed.