Skip to main content

⚖️ Arbiter — Submittal Compliance

The ones that bounce are never the ones you worried about.
Arbiter reads the governing specification section and the submitted product data and returns a verdict on every requirement — met, not met, or cannot be determined — with the specification paragraph and the submittal page behind each one.
Run one you already reviewed.

The problem

You review the packages experience marks as high-risk, and the rest move through faster than they should. That is not a decision you make — it is what forty-plus characteristics on a seventy-page cut sheet does to a week that already belongs to something else. Then the rejection lands, weeks later, on the parameter you waved through, and what you have to show for the review you did is a stamp. There is no record of which characteristics you verified, which you missed, and which the data never answered.
You did not do the line-by-line. Your project engineer did, and you cannot audit that review without performing it again. What reaches you is the return on the long-lead item, inside a procurement window that had no room in it, and the fabrication slot is already gone. The design team’s clock is the visible one and it is the one you talk about. The package left your own building unverified, and that part is not visible from where you sit.
Revise and resubmit, and the shop was scheduled to cut Monday. The stamp is not paperwork on your side of the table — it is the gate on fabrication release, material orders, and the billing milestone behind them. And you are proving compliance against a document set that reaches you second-hand and in pieces, which is why the rejection reads as the engineer being difficult when the record usually shows a substitution on the wrong form or a certification the section required and the package did not carry.
You have watched tools arrive and leave. Every one of them was a place to log something, which is why the rate never moved, and that conclusion was correct about the category. The objection you have is not that software is bad. It is that if it performs some of the checks you cannot tell which ones were done, which were skipped, which were done partway, and which were done wrong — and you are the one testifying if it goes sideways.
The standard lives in one person’s head and he is on a job in another state. You are asked to make a review process repeatable when the judgment in it was never written down, and what you are measured on is whether two projects were reviewed the same way. The log tells you where a submittal is and who is holding it. It does not tell you what was checked against what, which is the one thing an owner asks for when a dispute reaches the archive.

How It Works

Arbiter takes the governing section and the submitted product data and enumerates every technical requirement the section demands — every performance parameter, certification, listing, and referenced test standard, rather than the subset anyone expected to matter. It pulls the corresponding value out of the submitted documents and returns one row per requirement with one verdict on it. Where the submitted data does not answer a requirement, that is reported as cannot be determined, with the paragraph that required it and the page where an answer should have been. Where a page cannot be read at all, that is reported too, and every parameter depending on it is marked accordingly. Nothing is interpolated, nothing is inferred from the product family, and no typical value is ever supplied.

You hand over a section and a package. You get back three lists and you read two of them.

  1. 01
    Send the governing specification section and the submitted product data.
  2. 02
    Every requirement in the section is enumerated — not the ones you named, all of them.
  3. 03
    Each one comes back met, not met, or cannot be determined, with both source locations attached.
  4. 04
    The not-met and cannot-be-determined items sort by what they block — a fabrication release, a procurement date, or nothing.
  5. 05
    You check any line against your own documents in seconds, and you sign.
“Two not met, three cannot be determined, thirty-eight met — the coil coating is the one that would have bounced you, and the three unknowns need the engineering submittal, not the catalog sheet. You still sign. I do not.”
Arbiter

What it does

01
Lists every requirement in the governing section — performance parameters, certifications, listings, referenced standards — so nothing depends on you already knowing what matters.
02
Extracts values from cut sheets and product data running seventy pages and more, with fifty-plus technical characteristics on a complex package.
03
Returns one verdict per requirement — met, not met, or cannot be determined — never a score, never a confidence percentage.
04
Cites two sources on every finding: the spec paragraph that created the requirement and the submittal page that answered it.
05
Reports silence as silence — a parameter the data doesn’t answer comes back cannot be determined, never filled with a typical value.
06
Flags what it cannot read — scanned pages without text, illegible tables, missing sheets — and marks every parameter that depended on them.
07
Produces the same findings from the same inputs every run, so the record survives a challenge.
08
Runs before the package enters whatever portal the project mandates, and never asks you to change where you submit.

The Promise

Every requirement in the section enumerated. Both citations on every finding. Every parameter the data cannot answer reported as unanswered. Every unreadable input reported as unreadable. The same inputs producing the same findings. All five are verifiable inside one package, which is the reason they are the promises.

What it will not promise is a rejection rate. That number is the category’s headline and it is unverified, and a promise about how often a tool is right does not tell the person holding the stamp what happens on the occasion it is wrong. Automated extraction is imperfect and nothing here claims to have solved that. What is different is the failure mode: every parameter Arbiter could not verify to a citation is reported as unverified, so an error shows up as a gap you can see rather than a pass you cannot. The mistakes are supposed to cost you a redundant check. They are not supposed to cost you a false approval.

The conditions. The governing section and the submitted product data both have to be supplied. Where the documents are scanned images with no text layer, coverage degrades into cannot-be-determined findings rather than into false passes, and closing those takes readable documents. And the human signs. Arbiter produces evidence. The stamp stays with the person whose name is on it.

Objections

“How do I know it is right?”

Underneath the accuracy question is your signature, which travels with the review — an automated pass that is wrong becomes your error rather than the tool’s. Every line carries the specification paragraph and the submittal page, so you audit the machine in seconds rather than trusting it blind. What you will not get here is an accuracy percentage, because a percentage tells you the tool will be wrong sometimes without telling you where.

“If this is wrong on a critical-path item, that is my schedule.”

That is a correct observation about asymmetric exposure, and the answer is the third state. A tool that refuses to guess routes the honest unknown to human review instead of into procurement. A confidence score would ask you to price a probability against a fixed fabrication slot, which is not help.

“Not paying for another portal.”

You already work inside a platform a general contractor chose, and every project may bring a different one. This runs before the package enters that portal and never asks you to submit anywhere else. An integration promise would be the wrong answer, because integrating with the mandated portal still lands inside the thing you resent.

“I cannot tell which checks it did and which it skipped.”

That is the most precise objection in this domain and it is the one the output is built around. Every requirement in the section is enumerated and every enumerated requirement gets a verdict. Nothing is unreported, partial completion is not a hidden condition, and the output can be counted against the section itself.

“We are standardized on our current platform.”

Then keep it. Arbiter produces an artifact rather than becoming a destination — a compliance record that exports into whatever system the project mandates. You standardize the output without standardizing the system, which is the commitment that burned you last time.
Take a package you already reviewed and returned. Run it.

Check the citations against your own documents rather than checking the verdicts against your memory. If a citation lands on the wrong paragraph, you have learned everything you need in ten minutes and it cost you one closed package. If it names something that was in the documents the whole time, you found it somewhere other than in a returned submittal.

The value that bounced your package was in the documents the whole time — no one has enough attention to check every parameter every time, and that was always an arithmetic problem rather than a diligence one.