# Quoting Pilot Acceptance Workbench — build plan

**Access:** free downloadable source starter; self-build, self-deploy and self-maintain.

**Current package:** prompt, minimal TypeScript API-call example, README and this build plan. It is not a complete application.

## Outcome

Compare pilot outputs with estimator-approved references and assemble the evidence for a release decision.

**Users:** Estimating champions, operations leaders and sponsors evaluating quoting automation.

**Replaces:** Informal demonstration scoring, manually collated error spreadsheets and reliance on average extraction accuracy.

## Inputs
- Authorised unfamiliar test bids and document manifests
- Estimator-approved reference outputs
- Supplier outputs and configuration identifiers
- Buyer-defined error severity and acceptance rules
- Preparation, checking, correction and waiting-time records

## Outputs
- Source-linked discrepancy and omission register
- Critical-error review queue
- Preparation, review and correction comparison
- Acceptance evidence pack with unresolved gates and regression cases

## MVP screens and workflow
1. **Frozen test manifest:** Select authorised unfamiliar bids, reference outputs and supplier configuration. Freeze file hashes and versions before running a comparison.
2. **Discrepancy review:** Compare expected and returned fields, identify omissions and unsupported additions, and attach source references. Review proposed consequence classifications.
3. **Effort + coverage:** Report coverage separately from accuracy of returned fields. Compare preparation, checking and correction time; show waiting time separately.
4. **Acceptance evidence pack:** Apply buyer-approved gates, retain unresolved critical issues and capture a human release decision. Export regression cases with the decision record.

## Proposed records
- Run: manifest hash, reference version, supplier configuration, rule version
- Expected item: identifier, field, approved value, source pointer
- Observed item: value, linked reference, omission/discrepancy category
- Review: proposed severity, confirmed severity, reviewer, resolution
- Timing: preparation, checking, correction, waiting, baseline basis
- Gate: criterion, evaluated result, unresolved reasons, release decision

## Rules and review controls
- Coverage uses the expected-reference denominator; returned-field accuracy uses the explicitly defined returned-field denominator. Show both counts and the buyer’s definitions.
- Active effort = preparation + checking + correction. Keep waiting time separate and compare equivalent bid scope.
- Freeze inputs, references, configuration and acceptance-rule versions so a result can be reproduced.
- The model may propose a consequence classification; an authorised reviewer confirms it.
- Only buyer-defined gates decide pass/fail eligibility. Missing gates produce an unresolved status.
- Retain critical issues and regression cases even when an aggregate metric improves.

## Integrations

Authorised test-file upload; supplier-output import; reference and timing-sheet import; versioned evaluation store; workbook/evidence export.

## Build sequence
1. **Define the acceptance contract:** Agree a reference schema, field tolerances, severity rules, timing definitions and decision authority.
2. **Build reproducible runs:** Import references and outputs; hash manifests and configuration records; keep immutable run versions.
3. **Add evidence review:** Implement deterministic comparison, separate coverage and accuracy, and a reviewer-confirmed critical-error queue.
4. **Release the starter:** Export acceptance packs and regression fixtures. Validate that unresolved gates cannot disappear behind summary metrics.

## Acceptance checks
- [ ] An omitted item reduces coverage rather than disappearing from the denominator.
- [ ] An unsupported extra field is recorded instead of silently accepted.
- [ ] A critical unresolved discrepancy keeps the relevant gate unresolved or failed under the approved rules.
- [ ] Missing acceptance rules prevent a pass result.
- [ ] Changing the source manifest or configuration creates a new run version.
- [ ] Preparation, checking and correction are counted once; waiting remains separate.

## Shared implementation foundation

These are proposed build plans, not claims that the downloadable examples implement the finished tools.

- Start with authorised, bounded uploads and CSV/JSON imports. Add read-only connectors only after the upload workflow passes review.
- Store source references (file, page or message locator, version and extracted excerpt) beside every derived field. Record unavailable evidence explicitly.
- Separate model extraction and suggested matches from deterministic calculations and reviewer decisions. Treat uploaded document text as data, never as system instructions.
- Keep provider keys on the server. Validate inputs, output schema, file types and size limits. Handle provider failures without treating an empty result as success.
- Design project-level access, retention/deletion and an audit trail before handling live contractor records. The starter example does not implement these controls.
- Package setup steps, environment-variable descriptions, a synthetic fixture set, regression checks and a deployment/runbook. The operator supplies hosting, model/API usage, monitoring, backups and maintenance.
- Do not claim measured savings, accuracy, production readiness or a research-backed score. The attached material does not establish them.

## Release sequence

1. Agree schema, workflow boundary and contractor-approved rules.
2. Build upload, evidence review and deterministic calculations.
3. Add export and exception-handling paths.
4. Run the acceptance cases with authorised synthetic or redacted fixtures.
5. Document deployment and operational ownership before live use.