Every finding shows its work.
A verdict you can't trace is a liability, not a finding. Every result Nudgy returns carries a defined severity, a plain-English explanation, and a citation to the exact section and paragraph of the spec it rests on.
- Statuses
- Conflict · Warning · Compliant
- Severities
- Critical · Major · Minor
- Citation depth
- Section → clause
- Per element
- One finding
Statuses & severities
Two axes, formally defined
Every element gets a status — what kind of condition it's in. Every issue gets a severity — how much it matters. Both are assigned by definition, not by mood: the same condition produces the same result on every project, every time.
The status — what the audit found
A requirement in the spec is violated — the schedule says one thing, the spec demands another. Carries a severity and an action required.
A condition the documents can't confirm either way. Flagged honestly for human verification, never guessed into a verdict.
Checked and passing. Compliant elements are recorded, not discarded — the audit trail shows what was verified, not only what failed.
The severity — how much it matters
Life-safety or accessibility violation — fire ratings, egress, ADA. Correct before the set goes out.
Code or spec violation requiring correction. Not life-safety, still non-compliant.
Non-compliant with limited impact — finish deviations, missing accessories, mounting heights. Cheap to fix on paper, expensive to discover in the field.
Every finding also names its error source: a drawing error, an error in the spec document itself, or — this tag — a condition whose resolution depends on something the documents can't show: existing conditions, installed products, field dimensions. Routed to a human to confirm on site.
Cited, literally
The spec opens beside the finding
These are the controls reviewers actually get: View spec opens the cited section side by side with the finding, the clause it rests on highlighted — read it, confirm it, or overrule it. Ignore sets a finding aside without deleting it.
Anatomy
What a finding is made of
- ELEMENT
- The specific door, fixture, or unit — named the way the schedule names it.
- STATUS + SEVERITY
- A status — conflict, warning, or compliant — and, on every issue, a severity. Definitions are fixed; no judgment calls per project.
- ERROR SOURCE
- Who owns the fix: a drawing error, an error in the spec itself, or a condition that needs field verification.
- EXPLANATION
- Plain language a reviewer can act on without re-deriving the logic.
- CITATION
- Spec section and paragraph, down to the clause — the requirement text itself, one click away.
Conversations in context
When a finding needs a conversation
Findings are written to stand on their own — and when one raises a question, you ask it right there. Chat opens inside the audit result with the run's findings and the project's spec index already in context: why a requirement applies, what the fix scope is, where else the same clause bites. Answers cite their sections, like everything else Nudgy says.
Findings run in both directions
When the error lives in the spec — a contradiction between Part 1 and Part 2, a reference to a superseded standard — the finding names the spec as the document in error. The drawing is not always the suspect, and an auditor that assumes otherwise misses half the problem.
08 71 00 — Door Hardware (spec document)
Part 2 closer grade contradicts the standard referenced in Part 1 for exterior openings.
No black boxes
Every verdict is traceable to quoted requirement text. If Nudgy says a hardware set fails, it shows the clause that says so — and if a reviewer disagrees, they are disagreeing with the spec, not with an algorithm's opinion. That distinction is what makes findings usable in a profession with liability exposure.
