Case study 04 — Property feasibility platform

TerraScope AI

Development feasibility starts with a pile of zoning documents and a title deed, and ends with a number someone will commit capital against. The interesting engineering is in the middle: extracting constraints you can defend, generating concepts that respect them, and costing the result without a language model inventing the figure.

Next.js
FastAPI
Supabase
RAG pipeline

TerraScope workspace showing extracted zoning constraints with source snippets

The problem

Feasibility work means reading zoning schemes, title documents and stand schedules by hand, transcribing constraints into a spreadsheet, sketching what fits, and costing it from experience. Every step loses the link back to the document that justified it — which is exactly the link a reviewer asks for.

What we built

The workspace runs as a sequence of tabs — data room, intelligence, site details, brief, concepts, costing, report. Documents are ingested and extracted chunk by chunk with a verify or reject decision on each; constraints carry the snippet and confidence they were drawn from; concepts are generated and scored; costing is computed deterministically; and the feasibility report is the deliverable.

How it works

A data room where extraction is reviewed, not assumed
Zoning documents and title deeds are uploaded and extracted per chunk, each with a verify or reject decision. Nothing enters the model of the site because the extractor was confident — it enters because someone accepted it.
Constraints that keep their source
Zoning, coverage, height, setbacks and floor area ratio are each shown with the source snippet and a confidence score. When a reviewer asks where a height limit came from, the answer is on screen rather than in someone's memory of a PDF.
Stand schedules read as structured data
Stand schedules are extracted into structured rows with their originating snippets attached, turning a scanned table into something the rest of the pipeline can compute against.
Concepts generated and scored against the brief
Concept generation produces several options rather than one answer, each scored on privacy, view quality, buildability, cost efficiency and compliance confidence — so the trade-off between them is visible instead of implicit.
Costing that is computed, not generated
Cost estimates are deterministic, presented in rand with ranges, a confidence percentage and a breakdown by element. Where an input is missing the estimate says so explicitly rather than quietly assuming a value — a model-guessed construction cost is worse than no cost at all.
The report as the deliverable
The feasibility report is assembled from the verified extraction, the chosen concept and the costing, so what leaves the platform carries the same traceability the workspace does.

In the product

Data room with per-chunk document extraction and verify controls — Extraction is reviewed chunk by chunk, not accepted wholesale.

Planning constraints with source snippets and confidence scores — Every constraint keeps the snippet it came from.

Stand schedule extracted into structured rows — Scanned schedules become data the pipeline can compute against.

Generated concepts scored on privacy, buildability and compliance — Several concepts, each scored — the trade-off stays visible.

Deterministic cost estimate with ranges, confidence and missing-input warnings — Costing states its uncertainty instead of hiding it.

Outcome

A feasibility workflow where every constraint traces to a document, every concept carries its score, and the cost estimate is computed with its uncertainty stated rather than presented as a single confident number.

Have a system like this in mind?

Tell us the workflow you are trying to fix and we will tell you what it would take to build.

Start a conversation

TerraScope AI

Next.js

FastAPI

Supabase

RAG pipeline

The problem

What we built

How it works

A data room where extraction is reviewed, not assumed

Zoning documents and title deeds are uploaded and extracted per chunk, each with a verify or reject decision. Nothing enters the model of the site because the extractor was confident — it enters because someone accepted it.

Constraints that keep their source

Zoning, coverage, height, setbacks and floor area ratio are each shown with the source snippet and a confidence score. When a reviewer asks where a height limit came from, the answer is on screen rather than in someone's memory of a PDF.

Stand schedules read as structured data

Stand schedules are extracted into structured rows with their originating snippets attached, turning a scanned table into something the rest of the pipeline can compute against.

Concepts generated and scored against the brief

Concept generation produces several options rather than one answer, each scored on privacy, view quality, buildability, cost efficiency and compliance confidence — so the trade-off between them is visible instead of implicit.

Costing that is computed, not generated

Cost estimates are deterministic, presented in rand with ranges, a confidence percentage and a breakdown by element. Where an input is missing the estimate says so explicitly rather than quietly assuming a value — a model-guessed construction cost is worse than no cost at all.

The report as the deliverable

The feasibility report is assembled from the verified extraction, the chosen concept and the costing, so what leaves the platform carries the same traceability the workspace does.