Trust

It refuses to make things up — and you can prove it.

A proposal that invents a project, misstates a fee or names the wrong licence number is worse than no proposal at all. MinerSOQ is built so that every claim in a draft is either backed by your evidence or visibly marked as not.

Project references are verified

A reference to past work has to appear in evidence the model actually saw — a project sheet, a prior SOQ, a resume from your own archive. If it doesn’t, the draft keeps it visibly marked unsupported until an engineer resolves it.

Numbers are verified too

Every dollar amount, hours figure, percentage, date and count a section states must appear in the evidence, in your inputs, or in the firm profile. Otherwise it is marked. A number is never quietly rounded, updated or invented.

Fees are computed, not composed

Fees, rates, schedules and insurance limits are built by code from the tasks you entered and the profile you maintain. The model contributes the narrative around them and nothing inside them.

Gaps are flagged, not filled

When a section needs something the archive doesn’t contain, the draft says “PE input required” and names what is missing. It reads like the question list your engineer of record would send the client anyway.

What a reviewer sees

Three marks, and what each one means.

The markers are in the draft in the console and in the Word document. They are additive — the verifier can mark a claim, but it can never remove or rewrite one.

Relevant Experience · generated section

Elm Creek Lift Station Rehabilitation

Acme Engineering replaced the wet-well pumps, controls and force-main tie-in under a phased bypass plan that kept the station in service throughout construction (WT21-117 — Elm Creek Lift Station Rehabilitation).1The team also provided construction-phase submittal review and start-up support for the district (WT19-042 — Ridgeview Sewer Rehabilitation[UNSUPPORTED]).2

FLAG: PE INPUT REQUIRED — survey limits and vertical datum for the corridor3
  1. A checked reference. The project number appears in evidence the model actually saw — a project sheet in your archive. It is set in italics so a reviewer can see what was cited.
  2. An unsupported reference. The verifier could not find this project number in the evidence, so the marker stays in the draft until an engineer resolves it. Nothing is deleted and nothing is quietly rewritten.
  3. A flag, not a guess. The section needed a fact the archive does not contain. Instead of plausible filler, the draft names the gap — the question your PE would ask the client anyway.
A paragraph of a generated transmittal letter in the console, with four project references set in italics where the verifier found them in the evidence.
The same markers in a real draft: every italic reference was found in evidence the model actually saw.

Guarantees, not promises

Properties enforced in code — and tested.

The behaviours a firm relies on aren’t left to prompt instructions or good intentions. They are structural properties of the product, each backed by automated tests that fail the build if the behaviour ever changes.

Two outcomes per section

A section is either grounded in enough evidence or it isn’t. The second case is stated, flagged and left for a person. There is no third path where plausible text flows through.

A tamper-evident audit

Each proposal carries a keyed chain binding the inputs, the outline, the evidence, the model identity and every section, in order. Change any link and the chain no longer verifies.

Replay against the index

Verify audit re-derives the chain and checks that every cited document is still present in your index. It runs whenever you ask, without re-running the model.

References only in the browser

Search and proposal pages show document references — file, type, discipline, pages — never passage text. The wire format has no field for it.

Access enforced in the database

A document you weren’t granted doesn’t exist for you; it isn’t merely hidden. Row-level security applies to every query, including the ones the generator makes on your behalf.

One source for firm facts

Rates, insurance limits, staff counts, licence numbers and office addresses come from the firm profile you maintain — the only place a number can come from other than the archive or your inputs.

The result of Verify audit in the console: a status callout reading MATCH, chain intact, cited chunks present, model identity matches.
Verify audit replays the evidence chain against the index and reports whether it is intact — without re-running the model.

Honest about limits

A flag is the product working.

A first draft usually carries a handful of PE-input flags: survey limits, the vertical datum, how many review cycles the client expects, what the client will furnish. Those are not defects in the draft. They are the questions your engineer of record asks before committing to a scope — surfaced on the first pass instead of the last.

Still your judgement

An engineer signs, not the software.

Every draft leaves as a draft: banner in the header, markers highlighted, audit attached. Resolving a flag, accepting a reference, approving the fee — those stay with the people whose licence is on the cover, with an attestation record that says who reviewed what.

Try to make it invent something

The most convincing pilot is adversarial. Ask for a project the archive doesn’t have and watch what the draft does instead.