Quickbase · data integration
inspection-reconcile
Is an inspection documentation package actually ready for review? This tool compares the work a project requires with the inspections, documents and approvals actually captured, explains every gap with the exact source rows, and never says “ready” on evidence it could not see.
Live verification · 9 October 2026
Verified end to end against a live Quickbase app
The tool built its test app in a real Quickbase realm through the REST API, captured it back read-only, and assessed what came back. Synthetic data only.
Completeness was earned three ways: Quickbase's record totals matched, two read passes agreed, and the operator attested full read access.
The design
Three facts drive it
A checker that only looks at the records it was handed will happily approve an incomplete package.
Valid rows are not complete work
Expected work comes from an independently accepted scope, never from the records being checked. Thirty-nine valid inspections cannot satisfy forty obligations.
Absence from a partial view is not absence
Every finding is PASS, FAIL or UNKNOWN, plus NOT_EVALUATED behind a failed prerequisite. If the capture can't decide, the answer is UNKNOWN, and it says what would resolve it.
Approvals go stale
An approval binds a specific inspection revision and a SHA‑256 over the exact evidence bytes. Replace one photo under the same label and the approval no longer counts.
The Quickbase side
Built from the published API contract
The adapter follows Quickbase's official OpenAPI document and field-type pages, and it is careful in the places integrations usually aren't.
The client allows exactly four read operations: getFields, getTable, runQuery and downloadFile. The check runs before any request, so nothing can write or delete. The token comes only from the environment and is redacted from every message, log and file.
The mapping names fields by ID and is verified against the live field list, type and mode included. A renamed label changes nothing; a changed type stops the capture with a clear error instead of silently misreading data.
Keyset pagination by Record ID#, per-page total accounting, and a second pass that catches records changed mid-capture. Only a read that passes all of it is declared complete.
One command builds the test app's tables, fields, relationships and data through the API. It can only create, only inside the app it creates, never deletes, and the reader never imports it. A refused request stops cleanly and creates nothing.
What the report shows
Every finding carries its evidence
Each report is one self-contained HTML file: no scripts, no external requests, identical bytes on every operating system. Every finding has its expected and observed values, a resolution, and the source rows it cites.
How it is tested
Built so a wrong answer has nowhere to hide
- Expected results for 24 scenarios were written by hand from the specification before the engine existed, then re-derived independently. The tests never compute an expected verdict with the code under test.
- About 900 automated tests, including five deliberately injected defects that must each be caught.
- CI on Windows, macOS and Linux with Python 3.12 and 3.13, comparing every scenario's evaluation identity and report digest across all six.
- An SQL cross-check:
export-sqlitewrites the snapshot to SQLite, and independent queries re-derive the engine's answers. - Independent review passes against the specification, each confirmed defect fixed with a regression test.
Run it yourself
About five seconds, no account needed
Python 3.12+ and uv. The demo runs offline: it assesses every scenario and checks each result against the oracle.
# clone, install, run every scenario
git clone https://github.com/bochen2029-pixel/inspection-reconcile
cd inspection-reconcile
uv sync --all-extras
uv run inspection-reconcile demo --all --out out/demo
The manual
Two guides, tested like the code
Every command the guides annotate with an exit code runs in CI and must exit as printed.
User Guide · 35 pages
Running an assessment, reading the report, the four outcomes, the eight checks in plain language, comparing two runs, and a guided tour of six scenarios.