Scaffolding application

Prerequisites

None

Required documents

Engineers must provide both sides of their CISRS card:

Document	Files	Required
CISRS card	Front and back of the card	Yes

The card is a single document holding two files, the same shape as the Gas Safe and ECS cards. The backend keeps a record per side, each carrying its own expiry, but the app only ever writes one date to both — so the front's expiry is the card's.

CISRS card

CISRS (Construction Industry Scaffolders Record Scheme) details are captured on one screen alongside the two photos:

Field	Validation
Card type	Advanced (Gold) or Basic (Blue)
Registration number	Digits only, 8 to 20 of them
Expiry date	Required, must not be in the past
Front photo	Required
Back photo	Required

The card has one expiry date, shared by both photos — the form asks for it once and saves it against each side.

Scaffolding terms

Below the card details, the engineer must tick I agree to Zuno's Scaffolding Terms and Conditions before Submit for review becomes available. Tapping the link opens the terms at https://zuno.trade/engineer-agreements-scaffolding-terms without leaving the app.

The date the application is submitted is recorded as the date the terms were accepted. The box starts unticked every time, so an engineer resubmitting after a rejection agrees again, and the acceptance date moves to the new submission. Updating the CISRS card from the documents manager does not ask for the terms, because it does not resubmit the application.

How the photos are saved

Unlike the ECS and Gas Safe cards, which hold their photos and send them as base64 on submit, scaffolding uses the signed-URL upload path:

1. Each photo goes to S3 as soon as it is taken, and its storage path is held locally
2. On Submit for review, one update sends the card details and both stored paths with the shared expiry date
3. The application is then submitted

Both sides travel in that single update because the backend validates the card as a pair: each document needs a file path and an expiry together, so neither side can be saved on its own.

The capture screen starts from whatever card is already on the engineer's record — for example one ops uploaded in admin, or one kept from earlier. Both sides start filled and the card type, registration number and expiry are pre-filled, so either side can be viewed or retaken on its own, or the engineer can tick the terms and submit without photographing the card again. Whichever side the engineer leaves alone is sent back as it is. With no card on file, both sides must be photographed.

No document is associated with the engineer until submit, so a photo taken and then abandoned leaves nothing on their record — only an unreferenced file in storage. Local upload state does not survive an app restart, so a photo taken but not yet submitted is lost, and the screen starts again from whatever is on file.

Updating the card from the documents manager

The Trade tab shows one CISRS card row. Tapping it offers View document, which opens the card detail — both sides in a carousel, plus card type, registration number and expiry — or Update document, which opens the same capture screen as the application flow with ?updateMode=true.

The row routes rather than replacing in place because the update endpoint declares all_or_none_of :cisrs_card_front, :cisrs_card_back and requires a file path for each side, so a single-sided replace is rejected with a 422. The whole card is edited at once instead.

As in the application, both sides start filled from what is on file, so replacing one photo, or only correcting the expiry, is a normal save rather than a reason to photograph a card that has not changed.

Update mode stops at the update call and never submits: the application has already been reviewed, whatever its status. It does, however, change the status of an approved application — the backend deactivates one whose critical documents change (deactivate_after_update?), and the app renders an approved-but-inactive application as paused. Pending and rejected applications keep their status.

API endpoints

Action	Endpoint	API Version
Start application	/engineers/{userId}/scaffolding-application/start	rolling
Update application	/engineers/{userId}/scaffolding-application	rolling
Submit application	/engineers/{userId}/scaffolding-application/submit	rolling
Upload document	Application-specific URL via S3 signed URL	rolling

Job types

There is no scaffolding job type yet. The application captures the trade and its documents so engineers can be onboarded ahead of the work existing.

Dependent applications

None