Groma

Every quantity needs an explanation

Drywall takeoff requires more than recognizing lines in a PDF. The estimator needs to know what each wall represents, which faces carry board, and the height assigned to each face. When a quantity loses that connection to the drawing, checking it or explaining a correction becomes difficult.

Groma grew from that problem, informed by the family firm's estimating practices and field knowledge. The product aims to preserve the relationship between document, geometry, construction criteria, and quantity.

My role: from estimating practice to product

I founded Groma and translate estimating practices into product requirements. I check outputs against plan sets and direct implementation using AI development tools. My responsibility is to define what an estimator needs to inspect and correct—and recognize when the evidence is insufficient to accept a result.

The technologies describe the project's architecture, not equal personal coding fluency across its stack. AI assistance is part of development; human review remains part of the product.

One physical wall, two faces to review

The reviewed calculation identifies unique physical wall edges and retains stable edge and source identifiers. For each drywalled face, it calculates length times resolved height. A wall shared by two rooms therefore does not become two physical walls, although both faces can contribute area.

The interactive example uses two fictional rooms measuring 11 × 10 and 9 × 10 feet. They share a 10-foot wall; a 3-foot gap leaves 7 feet of solid wall. With two 8-foot-high faces, the displayed result is 56 + 56 = 112 ft². The geometric bridge closing the gap contributes zero board.

This demonstration was independently authored. It compares heights of 8 or 9 feet and gaps of 0 or 3, for the central wall only. It excludes headers, opening reveals, layers, waste, prices, exteriors, and ceilings. It does not run Groma or process client drawings.

Corrections change the calculation's inputs

The implementation includes a Next.js interface, a Python/FastAPI service, and Postgres. Its records retain the references needed to connect geometry, review, and quantities.

Supported corrections change source inputs, not just the displayed total. The review route validates fields, records their old and new values, and queues recomputation. It does not permit arbitrary property edits or resolve every geometric case.

Three boundaries the system must preserve

Closing a boundary does not create material. An opening_bridge edge closes topology but has faces=[] and contributes zero board. It is not a general door or window area-deduction mechanism. Assembly layer count is not a multiplier in this calculation either.

Missing information is not invented. A missing height or unresolved face blocks quantification for review. Choosing a default height would produce a complete-looking number without sufficient support.

A correction must target the reviewed version. The route rejects unknown fields, duplicate entries, and a stale artifact hash. It distinguishes a 409 stale_revision conflict from 422 validation_failed, separating an invalid input from a review whose underlying version has changed.

Executed tests, with a bounded scope

On October 3, 2026, this case was checked against source revision c058543c66e24f42ae377f7cb417719ca7360029. Sixteen selected tests in pipeline/tests/stages/test_quantify.py passed in an isolated copy, with network access denied, credentials cleared from the environment, and dotenv loading disabled. The run reported five PyMuPDF deprecation warnings.

The tests use the generated synthetic PDFs two_room_shared_wall and door_gap_water_closet. They exercise ingestion, scale, geometry, reading and reconciliation with scripted model responses, and quantification. They are not a complete browser-to-service or production end-to-end test, nor an accuracy measurement on client drawings. The published QA image also uses a synthetic plan; it does not document production use.

Read the verification summary · JSON. It records the source revision, isolation conditions, coverage, and result boundaries without exposing private code or client drawings.

From a correction to an approved output

A separate offline API integration test passed on the same date and source revision. It followed a synthetic plan through sheet confirmation, review, a height correction from 8 to 9 feet, recomputation, approval of a specific bid revision, and export retrieval. The correction produced a new quantities revision and a changed price.

This was an in-process test with in-memory data and storage, scripted model responses, and a file placed in storage by the test—not a browser upload or a production workflow. The run reported 93 deprecation warnings.

The XLSX output was retrieved and its ZIP signature checked; its contents and formatting were not independently reviewed. PDF rendering remains unverified: the output labeled PDF was an HTML fallback because a native rendering library was unavailable. A passing lifecycle test does not establish a valid PDF.

Read the API lifecycle verification · JSON. The record distinguishes the tested source revision from the fixture's placeholder provenance and documents the configuration, export observations, and remaining limits.

Implemented modules; integration in development

Groma has implemented extraction, review, and estimating modules. The reviewed evidence supports specific calculation and correction mechanisms—not a complete estimate or an automatic handoff to Minera. That integration remains in development and validation. The house on this site comes from a Minera model; it does not demonstrate Groma extraction.

The repository remains private. I do not publish adoption, accuracy, or savings figures without approved measurements. Next are geometric coverage, the corrections required from an estimator, browser-to-service continuity, and rendered export quality. The synthetic tests narrow those questions; they do not settle them.