Raising a blocker

Every way of raising a Blocker funnels into the same record and the same pre-filled confirm form. What differs is only the entry point and one thing: whether the record enters suggested (waiting for a coordinator) or confirmed (live at birth). Nearly everything is a suggestion: a raise self-confirms only from a door that asks who is responsible (the desk declare and mark-clash-as-blocker), driven by somebody holding blocker_triage, about their own firm's work. A QS's declare, any cross-firm declare and every other door land in the queue. This page walks each intake.

For Field member (mobile capture)

Your role

You are the person who hits the stoppage — you down tools because the access is gone, the lift is grounded, the trade in front of you never finished. Your job is to suggest it, fast, from your phone. You never mint an active blocker; you drop a suggestion into the coordinator's queue, and they confirm it. You need blocker_suggest — held by every member, and by HSE too.

Task 1 — Raise a blocker on the phone ("What's in the way?")

The sheet is a two-tap raise. Its required path is five questions, and everything else — the work pick, the counts, the cause, the tag — sits behind one fold, Add details (optional). A gloved supervisor standing in the rain answers the five and sends it; the crew's clerk who has the figures to hand opens the fold and gives them.

1. From the mobile site-home launcher, tap Raise a blocker. (The tile shows only if you hold blocker_suggest.)
2. The sheet opens on "Did work stop, or just slow down?" — the extent question, asked first and never inferred.
3. "Whose work stopped?" — asked only when you are raising for another firm. Your own firm is the answer otherwise, and the step never renders.
4. Say when work stopped — an absolute site-local instant, pre-filled with the moment you are declaring and freely editable. (The four relative chips — just now · 15 min ago · 1 h ago · 2 h ago — were withdrawn: they capped retrospective declaration at two hours, so a 06:00 start declared at 09:41 was unconstructible. A clamp chip may still offer a derived instant beside the field, on tap — it never writes itself into it.)
5. Optionally add a photo, then write the note — "What's in the way?" — which is owed on every raise. The record's story is a human sentence every time, and it is the first thing read at the coordination meeting. Your location rides along as a quiet one-liner beneath it.
6. Submit → POST .../blockers/suggest. The blocker enters suggested and lands in the coordinator's triage queue. That's you done — no further action needed.

Inside Add details (optional) — open it if you have any of this to give:

• The pick-your-work band, headed "What can't proceed?": pick which of your own work today is stopped — it is scoped to your crew's work on the current site-local day, and a "Near you" shelf floats the nearest rows to the top once your phone has a usable fix. The work you pick rides the same submit request.
• The two count questions, which appear once the pick leaves something to count against: how many were in the gang (M — this defaults from the crew you picked), and how many were sent home (S). Only S is multiplied into the lost-time crew-hours; the app stores S and the complement M−S, so a partial slowdown reads honestly instead of collapsing to zero. It never asks "how many kept working?" — that framing under-reads a real slowdown. Raising for another firm you get their standing statement here instead: how many of a firm's people stopped is that firm's own fact to state.
• The cause, and — for a cause that names a record (a delivery, a permit) — which one.
• A "Whose stuff?" tag, if you reckon another firm caused it.

Shut the fold again and its head reads Details added over a summary of what you set (Line B2-04 · gang of 6, 4 stood down · Plant breakdown · Keltbray's doing), so nothing you gave is hidden behind a closed lid. Merely opening and shutting it changes nothing at all.

Note: A raise that never opens the fold is complete and correct. It carries no work refs, no count and a cause of cause not given — recorded as unstated, which is not the same as Something else: one says no answer was given, the other names a cause the vocabulary lacks (and still owes its own note). It lands in the coordinator's Needs your count pile exactly as a raise with no work pick always did, and the coordinator supplies the missing figures at triage.

Note: It's always a suggestion. The phone never mints a live blocker, and it never sets blame — the "Whose stuff?" tag is a hint the coordinator can accept or ignore, not an accusation that lands. Coordinator vocabulary (extent, snag links, formal responsible party) is deliberately kept off the phone.

If you have no signal, tap Raise anyway. The sheet tries to send it, and if the wire is dead it saves the whole raise on the phone — your answers and your photos together — and says so: "Saved on this device", with Try now if you want to prod it. It goes out by itself the next time you are back online with SimOps open, and the screen turns into the ordinary Suggestion sent the moment it lands. Nothing is retyped and nothing is edited in between: what the site hears is word-for-word what you wrote.

Three things worth knowing about it:

• The blocker is not on the table until it lands. There is no phantom row on anyone's list and no badge anywhere — an unsent raise exists only on your phone. If you open the sheet again before it has gone, a strip at the top names it ("1 blocker you raised is still on this phone"), so it cannot be forgotten.
• No knock-on from an unsent raise — a knock-on has to point at a record the site has, and this one has not arrived yet. Chain it once it lands.
• A raise the server refuses still says so in the server's words. After a few tries the strip reads "Sending keeps failing" with the refusal beneath it and a Try again; only you can tell whether what you wrote can be fixed. And if the phone itself cannot save it (private browsing, a full device), the sheet says that on the spot rather than quietly dropping it — stay on the screen and try again.

Two things degrade offline, by design. The "What can't proceed?" list is a live read of your crew's work, so with no connection it reads "Can't load your work without a connection — you can still raise this." No work pick means no count questions either, so an offline raise is the five questions plus a cause and a tag — and lands in Needs your count like any other raise that gave no figures. The time work stopped is still yours: it is frozen in what the phone saved. What the site records as the declaring instant is when it actually arrived, so a dead zone reads honestly as reporting lag rather than pretending the news was instant.

Task 2 — Say "we're moving again" (close your own raise)

The close has its own door on the launcher: Still stopped, in the My work band beneath Your firm's lost time. Its badge is the number of stopped records you can close, so a glance at the home screen says whether anything is waiting on your word; nothing owed, no badge. The tile is there either way.

(It used to be a strip at the top of the raise sheet. It was moved out: the sheet's job is to ask what has stopped, and a list of other records above that question was only muddying the waters. An empty tile reads "Nothing of yours is stopped".)

1. Tap Still stopped and pick the record, then tap the verb that fits. The still-stopped card carries two, and which two follows the record's own extent: a stoppage offers "We're moving again" and "Some are back"; a disruption offers "All back" and "Fully stopped". The first of each pair is a plain close; the second closes this record and raises a follow-on carrying the other extent, because the tap is the declaration and never inherits the parent's verb across the transition. A record whose extent was never declared gets a single tap instead of a pair — a machine must not guess which of stopped or slowed the reporter meant.
2. Say when the crew actually got going — the field is pre-filled with now ("we'll record now — hh:mm; tap to change") and is yours to correct. The close stamps work_resumed_at and shuts the loss window in one gesture.
3. If the close would land across a gap in your crew's presence, the app first asks what closing at that instant would do (a preview that stores nothing) and offers to split the window into dated segments — accept, decline, or close and raise a follow-on for loss that carried on.

Note: Triage state is not a precondition. A still-suggested raise can be closed exactly like a confirmed one — a crew should not have to wait on a coordinator to record that it is back at work — and closing launders nothing: a closed-but-suggested record's figures stay in the awaiting-triage tier and it stays rejectable. Only a rejected record refuses (there is no window left to close). Reach is the record's legal closers: the commercial band for anything in scope, plus any member of the record's own firm — the restart is a firm fact, not a personal one.

Task 3 — Chain a knock-on

If your stoppage is the downstream consequence of another one, tap the card's body on the Still stopped tile and then knock-on: it drops you back on the raise sheet with the upstream blocker already filled in as the cause, so the chain is one gesture across the two doors. Each knock-on is its own record with its own window and headcount; on the ledger they thread beneath the blocker they stem from, so the coordinator sees the chain, not a flat list.

---

For Coordinator / QS (desktop declare)

Your role

You already know the stoppage is real — so you declare it. The desk door itself is open to every holder of blocker_suggest (a desk person for a contractor included); blocker_edit is what turns the form's submit from Raise the blocker into Declare blocker, and whether the record is confirmed at birth is a further question again — only if you also hold blocker_triage and the record is not about another firm's work. So a coordinator's own-firm declare self-confirms; a QS's declare, and any declare naming another firm as the loser, enters the queue with everything else. You have several doorways into the same declare modal.

Task 4 — Raise a blocker from the desk

1. Press A to enter add mode, then B for Blocker — the fourth tile of the Add menu's Report group (Alert · Incident · Observation · Blocker), drawn for any holder of blocker_suggest: a member, a QS, an inspector, a coordinator alike.
2. B arms the map, exactly as its Report-group neighbours do. Your next click on the map anchors the blocker and opens the declare modal at that point; Escape cancels the arm and places nothing. (The Noticeboard's Blockers section carries no launcher of its own — when it is empty it points you back here.)
3. The modal is the phone's cut on a desk. Its required path is: the extent ("Did work stop, or just slow down?") · "Whose work stopped?" · when, and beside it Resumed (blank = still stopped) · photos · the description · the pin line. Everything else — cause, affected work, the gang-and-send-home counts, and (on the suggest arm) the "Whose stuff?" tag — sits behind the same one fold the phone has, Add details (optional). There is no Title field: the title is the description's first line, exactly as on the phone, and the description is owed on every desk raise.
4. Photos: paste, drop, or pick. The photo grid is the phone's own, with two doors a desk has and a phone does not — paste a screenshot straight into the open modal (⌘/Ctrl+V), or drop files onto the grid. Where a photo's own bytes carry a GPS point, its chip offers Use photo location: one tap moves the pin to that point. Remove that photo again and the pin goes back to where you clicked. Photos attach after the record is created, and they are held on the device until they are up — closing the modal never loses one.
5. The pin: move or clear. The modal always opens anchored on the click that opened it, so the two controls are Move on map and No single spot. Move on map minimises the modal to a chip — "Placing the blocker — click the map · Esc keeps the current pin" — and your next click moves the pin; the modal comes back with every field exactly as you left it, and Escape brings it back keeping the pin you had. No single spot drops the pin and the record then lists without painting one. (There is no place-from-nothing door: a pinless desk raise is click, then clear.)
6. The band changes the verb and one field, nothing else. The header reads Raise a blocker · Goes to the coordinator to confirm or Declare blocker · Confirmed at birth for your own site — a cross-firm declare goes to triage, and the submit reads to match. On the declare arm "Whose doing was this?" rises out of the fold onto the required path, because a birth-confirmed record owes the answer: leave it unanswered and the request is refused (422 blocker_responsible_required), and "Nobody — no firm at fault" is a first-class answer, not a blank. On the suggest arm it is a tag inside the fold and blocks nothing, and the count is offered only for your own firm's work.
7. Somebody messaged it in? Say so — Reported to us by…. The modal's last fold, collapsed and easy to scroll past on a first-hand raise, records what a forwarded report is: who told us (a name, free text — never a SimOps account), how it reached us (WhatsApp · email · a phone call · in person) and when they sent it. Leave the fold shut and the record is first-hand, which is what every phone raise is. Setting when they sent it offers a Use the message time chip on when work stopped — a report cannot precede the stoppage, so the message time is the latest honest default and you edit it down. The chip only ever fills a when you have not typed in: nothing here overwrites what you wrote. And the declaration stamp does not move — it stays the instant SimOps was told, so the ledger's recording lag measures what actually happened and cannot be typed.
8. A forwarded photo claims only what its bytes claim. A WhatsApp send strips a photo's EXIF and a forward re-sends the stripped copy, so a pasted WhatsApp image carries no taken-at badge and no location chip — and that silence is correct, not a bug (an email attachment usually keeps both). What a WhatsApp file name says is offered instead, as an editable received-on hint beneath the grid: one tap puts that day into when they sent it, where the field tells you it came from the file name so you can check it against the message. Nothing is ever recorded as a claim about the photo, and a relayed count is prose in the description — the firm speaks its own count in Needs your count, or at the meeting with its rep in the room.
9. Submit → POST .../blockers. A raise that never opened the fold carries no work refs, no count and a cause of cause not given (unstated) — complete and correct, and it lands in Needs your count exactly as the phone's does. A relayed record wears its three facts as told to us on its own panel, beside the declaration stamp, and the coordination meeting's table whispers the channel on the row (relayed · WhatsApp).

You can also declare from a pin: an incident, observation, alert or delivery pin's properties panel carries a Declare blocker action that pre-fills that pin as a locked cause — the quickest way to say "this incident stopped work." A doorway that has already answered the cause opens the fold for you, so the answer it put there is visible and correctable; a bare A → B raise arrives with it shut.

Task 5 — Turn a red clash into a blocker ("mark clash as blocker")

1. On a clash row — in the Noticeboard or a properties panel — click the ⛔ mark as blocker button.
2. This writes the clash stance and the blocker in one atomic transaction (if the audit write fails, neither lands), with the live clash episode pinned as the cause server-side. Like the desk declare it asks who is responsible, so it self-confirms under the same conjunct and otherwise queues. It's the one-click path from "these two are clashing" to "and it's costing us time."

Task 6 — Act on the "Delays" handoff (dependency violation)

1. When the dependency graph is contradicted, the Noticeboard raises a loud, un-collapsible "Delays" banner (a Dependency violation, a distinct item kind above red) — a hazard-diamond section above every red clash row, with no dismiss or ignore affordance, because a delay is never suppressible. Each delay carries a + Declare blocker button, drawn for anyone holding blocker_suggest rather than only for the coordinator band.
2. Click it → POST /api/dependency-violations/{episode_id}/declare-blocker. No form opens — the click mints the record server-side, with the violation episode locked as its cause. A triage-band clicker is then taken straight to the new record's pin panel ("Blocker suggested — review and confirm"); anyone else gets "Blocker suggested — awaiting coordinator confirmation". The upstream trade rides along as the raiser's tag (suggested_responsible_contractor_id), an offer the confirm select renders — the answered responsible_contractor_id stays NULL until a human decides it.
3. Whoever clicks it, the record enters suggested for normal triage: this door presents no responsible select, and a raise surface that cannot present the select posts a suggestion. A human always raises it — the delay never auto-creates a blocker.

Note: The delay handoff is the one intake that pre-derives blame (the predecessor/upstream line's contractor), which the confirm select then offers as a labelled option. Every other cause starts blank — you accept blame by hand at confirm, and the record stamps how you answered (responsible_provenance).

---

Permit-wait doorway

A crew held up waiting on a permit — one still in-flight, or expired-and-unclosed — can turn that wait into lost time straight from the mobile permit wallet:

1. On a waiting permit card in the mobile wallet, tap "Work held up by this permit? Declare blocker".
2. This opens the mobile Raise a blocker sheet pre-filled with the permit as the cause (cause_kind = permit, #1585), and follows the normal suggest path — so it enters suggested for triage.
3. To author the same thing at the desk instead, pick "Waiting on a permit" from the declare modal's cause list and choose the permit from the candidate sheet.

Note: The wallet card is a shortcut, not the only route. Since #1912 there is exactly one authored capture vocabulary (CAPTURE_CAUSE_KINDS) and every door filters it rather than carrying its own list — so "Waiting on a permit", "Waiting on others", "Plant breakdown", "Sickness" and "Safety hazard" are all reachable from the desktop declare modal too. Before that fix the desk carried a separate seven-kind list, which made those causes unreachable there.

---

Why a raise is a suggestion, never an active blocker

SimOps never mints an active blocker from the field, on purpose. A stoppage claim can be contested, cross-trade, or simply mistaken, and a live blocker is a site-wide, blame-bearing commercial record. So the field suggests and the coordinator band confirms: only a confirmed blocker is visible site-wide or carries an accepted responsible party. Until then it's private to its raiser and the commercial band, and it accepts no blame.

Waiting on triage does not mean waiting to count. A suggestion's crew-hours are in the lost-time rollup from the moment it is raised — in their own awaiting-triage tier, named for the missing act. Silence is not a decision, and a rollup that admitted only confirmed rows would let a coordinator's inaction shrink the site's loss. What confirmation adds is the blame axis, the site-wide visibility and the money; what rejection does is take the figures out, with a reason attached. The full triage flow is on Reviewing & triaging blockers.

---

See also: Blockers & delays overview · Reviewing & triaging blockers · Snags & work close-out · Reference.

Blockers guide: Overview · Reviewing & triaging · Raising · Snags & close-out · Reference