Help

Projects and per-job requirements

A project is not a folder. It is the unit that lets one job carry a stricter rule than the rest of your book, and the unit somebody else asks you about.

Why you would create one at all

You can run Sealinn without projects. Every subcontractor is measured against your default requirement set, the dashboard tells you who is short, and that is a complete answer for a contractor whose jobs all carry the same insurance terms.

Projects earn their keep in two situations, and both are somebody else's question rather than yours. The first is an owner or a general contractor above you who wants to know whether everyone on their job is covered — not your whole book, which is none of their business, and not a number that includes crews who have never set foot on the site. The second is a job whose contract demands more than you normally require, which is the case a per-job requirement set exists for.

If neither of those is true today, skip the feature. A project with no override and no external audience is a list you now have to maintain.

What assigning a subcontractor actually does

Assigning is not a label. It creates a link that carries its own compliance status, and that status is computed against the requirement set that applies to that project — the override if there is one, your default if there is not. The link is recomputed the moment it is created, so a sub you add to a stricter job shows their standing on that job immediately rather than at the next nightly sweep.

Removing a subcontractor from a project deletes the link and nothing else. Their documents, their history and their org-wide status are untouched — you have said they are not on this job, not that you are finished with them.

A subcontractor has more than one status, and this is the part that surprises people

The status on your subcontractor list is measured against your default requirement set. The status on a project is measured against that project's set. So a sub carrying $1M can read compliant on the list and non-compliant on the one job whose owner demands $2M — both are correct, and they are answers to different questions. When somebody quotes you a status, the useful follow-up is which screen they read it on.

Overrides, in practice

A project override is a second requirement set that sits over your default for one job. Anything you do not override falls through, so it is a short list rather than a second full configuration — what each field does is the same everywhere, and the guide on what to require before a sub starts is the same insurance question.

The sequencing does not matter, which is worth knowing because it is the thing people work around unnecessarily. Create the override first and assign subs afterwards, or assign subs and add the override later — either way the subcontractors on that project are measured against it. There is no re-apply step and no order you have to get right.

What that means on a running job is that adding a stricter override will move some subs to non-compliant the moment you save it. That is the override doing its job. It is still better done on a Tuesday morning than at five on a Friday, because the next thing that happens is a conversation with each of them.

The fraction on the projects list

Each project shows a compliant-of-total count. Both halves come from the per-project links, so the denominator is the crews you actually assigned to that job and the numerator is how many of them clear that job's rule. It is not a slice of your org-wide numbers.

That makes it the number to hand upward. The project compliance report is the same answer as a document — reports and exports covers the four report types and which question each one answers, and this is the one written for the person who does not care about the rest of your book.

A project can only ever be as accurate as the roster behind it. A crew somebody hired and never entered is not shown as missing on a project; they are absent, which looks the same on screen and is not the same thing. That is the same trap as anywhere else in the product and the fix is the same one — get everybody in first.

Archiving and deleting are different operations

Archiving sets the project's status to archived. It stays in the system, it keeps its subcontractors and its requirement set, and you can still find it by filtering for archived projects. This is the one to use when a job finishes — the completed-operations exposure on a construction job outlives the job by years, and the record of who was covered while the work was going on is exactly what a defect claim asks for later.

Deleting removes the project from every view and unassigns every subcontractor on it. The subcontractors and their documents survive — you are deleting the job, not the crews — but the record of who was assigned to it does not. Use it for a project entered by mistake, and archive for one that ended.

Both write to the audit log with a name and a timestamp, so a project that vanished has an explanation. What the log records is worth knowing before you need it.

One rule for most jobs, and a stricter one where the contract says so.

Projects exist for the job that is not like the others, and for the person asking about that job specifically.