Help
Custom documents and custom checks
Two things you define yourself: a document type beyond the four built in, and a check written in your own words that the reader evaluates on every arriving document.
A document type of your own
Sealinn ships with four: the certificate, a W-9, a contractor license, and a safety certification. Plenty of contractors need a fifth. A payment or performance bond. A mine-safety card. A client-specific form an owner insists on. A signed subcontract.
You add one by name in your requirement set, and it behaves like the built-in types from that point on. Mark it required and a subcontractor is incomplete until an approved document of that type is on file — the same rule the built-in toggles follow, which is set out in what each requirement field does.
The name you give it travels. It appears in the picker when you request documents, it is what the subcontractor sees on their upload page rather than something generic, and it is what the document is filed under afterwards. A sub asked for a "Mine safety card" knows what to send; a sub asked for an "other document" sends whatever they have.
There is also a one-off. If you need something from a single subcontractor and only once, you can name it when you request the documents without adding it to your standing requirements. It arrives, it is read, it is filed under that name, and it does not become a rule everybody else has to satisfy.
A custom document is read, not just stored
Whatever arrives goes through the same reader as everything else. Because the shape is not known in advance it is read open-ended — the model returns whatever fields are clearly labeled on the page rather than filling a fixed form — so a bond comes back with its number, its amount and its dates. Those values are yours to edit in review like any others, and how the reader decides what it is confident about works the same way here.
A check written in your own words
The second thing you can define is a check. The built-in checks are fixed because the things they look at are fixed — a limit is a number, an endorsement box is a tick. A custom check is a sentence you write, and the reader evaluates it against the document.
Two decisions come with each one: is it required, and which documents does it apply to. The scope matters more than it looks: a check can apply to every document, to one built-in type, or to one of your custom types. "The bond names us as obligee" belongs on the bond and nowhere else — leave it applying to everything and it will be evaluated against certificates it has nothing to do with.
What a check actually does to a status
There are three outcomes, and the difference between them is the difference between a useful check and a confusing one.
| The reader's verdict | What you see | What it does to the subcontractor |
|---|---|---|
| Not satisfied | A blocking violation, alongside the built-in ones | Holds them at non-compliant until it is resolved or overridden |
| Unsure | A warning, naming the check | Nothing — an uncertain reading is not evidence of a failure |
| No verdict at all | A warning saying it has not been evaluated yet | Nothing, until the document is uploaded again |
That third row is the one worth understanding, because it is what a new check produces on documents you already hold. A check is evaluated when a document is read. Add a check today and yesterday's approved certificates have no verdict for it — they are not silently failing and they are not silently passing, they say so. Re-uploading the document is what gets it evaluated.
The reason it works that way rather than retroactively marking everything non-compliant is that a rule you just wrote is not evidence about a document nobody has re-read. Flipping a book of subcontractors to non-compliant on the strength of a check that was never run against them would be the wrong kind of confident.
Overriding one, and what an override is worth
A blocking custom check behaves like any other blocking violation in review: you can approve the document anyway with a reason, and how that review screen works is the same whichever check raised the flag.
Two things about that override are deliberate and neither is visible on screen. It applies to that document only — the next certificate from the same subcontractor is a new document and earns its own decision, because a waiver that carried forward would quietly turn a required check into decoration. And the check does not go silent afterwards; it drops from a block to a warning, so the record still shows that this certificate did not satisfy it and that somebody accepted it anyway. Both facts are recorded with your name in the audit log.
Which is the honest way to think about custom checks generally. They are a reader's opinion about a sentence you wrote, not a measurement, and they are wired to fail toward a human rather than toward a silent pass — the full list of what blocks and what only flags shows where each one sits.
Your fifth document, and your own words.
Require what your contracts actually require, and have every arriving document read against it.