Threshold

Floor plan analysis highlighting accessibility barriers and suggested redesign improvements with AI-powered quote ranges
The landing page of our software

Inspiration

Floor plans describe the physical structure of a building, but they do not immediately explain whether someone using a wheelchair can reach the rooms that matter to them. Accessibility assessments often require people to manually interpret doors, corridors, thresholds, stairs, and turning spaces before they can consider possible modifications.

We built Threshold to translate a floor plan into a question that graph theory can answer:

Given an entrance and a set of important destinations, which rooms are reachable now, and what is the smallest set of physical changes that would make the remaining destinations reachable?

Our aim was not to replace professional accessibility assessment. Instead, we wanted to create an understandable planning tool that helps users inspect a building, identify possible barriers, and explore practical improvements.

What it does

Threshold accepts a raster image, PDF, or structured SVG floor plan and converts it into an editable building graph.

In this graph:

rooms and circulation spaces become nodes;
doors, entrances, ramps, lifts, stairs, and passages become edges;
physical measurements and features become graph attributes;
entrances become the starting nodes for accessibility analysis.

The user reviews the detected layout, corrects room names or connections, identifies an entrance, and calibrates the drawing using a known physical dimension. Threshold then evaluates the graph using wheelchair-accessibility rules.

Every room is placed into one of three states:

reachable — there is a confirmed accessible path from an entrance;
needs review — a path may exist, but at least one required measurement or property is unknown;
unreachable — every known path is blocked or the room is physically disconnected.

The user can select the rooms that matter most. Threshold searches through supported interventions—such as widening a doorway, lowering a threshold, modifying a ramp, adding a ramp, or removing an obstruction—and recommends the smallest combination that connects every selected destination.

The original physical graph is never deleted or rewritten as an “accessible” graph. Accessibility and proposed modifications are derived views, so the application preserves the difference between what physically exists and what could be changed.

How we built it

Threshold has a Next.js and TypeScript frontend supported by a Python FastAPI backend. The system is divided into four main stages:

floor-plan extraction;
human verification and scale calibration;
accessibility graph analysis;
minimum-intervention optimisation.

For raster images and PDFs, we use the Raster2Seq CubiCasa model on a remote RunPod GPU. Large plans are divided into overlapping tiles before inference so that individual rooms and doors retain more detail than they would after resizing the entire drawing to the model's input resolution. Predictions are transformed back into the original image coordinate system, deduplicated, and validated.

Structured SVG plans follow a deterministic vector-processing path. This preserves room polygons, labels, and door geometry without rasterising them.

The detector output is treated as an unverified candidate rather than ground truth. Malformed predictions are rejected, uncertain door relationships remain unresolved, and the user can correct the graph before confirming it.

Representing the floor plan as a graph

We model the verified building as an undirected attributed graph

$$ G=(V,E), $$

where each vertex $v\in V$ represents a room or circulation space and each edge $e\in E$ represents a physical transition between two spaces.

An edge has the form

$$ e={u,v}, $$

where $u,v\in V$ are the spaces connected by a door, entrance, ramp, lift, threshold, or open passage. Nodes and edges retain attributes such as

$$ v=(\text{type},\text{geometry},\text{area},\text{physical status}) $$

and

$$ e=(\text{type},\text{width},\text{threshold},\text{gradient},\text{features}). $$

This separates the building's topology—what connects to what—from the accessibility properties of each connection.

Inferring door adjacency

A detected door is represented by a line segment with endpoints $p_1$ and $p_2$. Its midpoint is

$$ m=\frac{p_1+p_2}{2}. $$

If $\Delta=p_2-p_1=(\Delta x,\Delta y)$, then a perpendicular unit vector is

$$ \hat{n}=\frac{1}{\sqrt{\Delta x^2+\Delta y^2}}(-\Delta y,\Delta x). $$

We sample points on opposite sides of the door:

$$ q_+=m+\delta\hat{n},\qquad q_-=m-\delta\hat{n}, $$

where $\delta$ is an adaptive sampling distance. An edge is created only when $q_+$ lies inside exactly one room polygon $P_u$ and $q_-$ lies inside exactly one different room polygon $P_v$:

$$ q_+\in P_u,\qquad q_-\in P_v,\qquad u\neq v. $$

If either side is missing or ambiguous, the system does not invent a connection. It returns the door for human review instead.

Accessibility as a derived subgraph

Each edge receives a tri-state accessibility classification:

$$ a(e)\in{1,0,\bot}, $$

where $1$ means accessible, $0$ means blocked, and $\bot$ means unknown because required evidence is missing.

The assessment considers minimum clear width, maximum threshold height, ramp gradient, physical availability, and obstructions. For example, a doorway may require

$$ w_e\geq850\text{ mm}, $$

while a threshold must satisfy

$$ h_e\leq20\text{ mm}. $$

A ramp is checked against the configured maximum gradient

$$ g_e\leq0.0715. $$

We construct the definitely accessible and possibly accessible edge sets:

$$ E_A={e\in E\mid a(e)=1}, $$

$$ E_P={e\in E\mid a(e)\in{1,\bot}}. $$

Given entrance nodes $S\subseteq V$, definite reachability is

$$ R_A(S)={v\in V : \exists s\in S\text{ with an accessible path }s\leadsto v}. $$

Possible reachability is calculated similarly using $E_P$:

$$ R_P(S)={v\in V : \exists s\in S\text{ with a path through accessible or unknown edges}}. $$

Therefore,

$$ R_A(S)\subseteq R_P(S). $$

A room is definitely reachable if it belongs to $R_A(S)$, uncertain if it belongs to $R_P(S)\setminus R_A(S)$, and unreachable if it is outside $R_P(S)$.

Calibrating image measurements

Floor-plan coordinates begin in pixels. If the user marks two points $p_1$ and $p_2$ with a known real distance $d_{\mathrm{mm}}$, the scale is

$$ s=\frac{d_{\mathrm{mm}}}{\lVert p_2-p_1\rVert_2}\quad\text{millimetres per pixel}. $$

This scale allows the system to convert detected geometry into physical widths, areas, clearances, and turning-space estimates.

Finding the minimum intervention set

Let $D\subseteq V$ be the destinations selected by the user and let $C$ be the supported candidate modifications. Each modification $c\in C$ transforms the physical graph into a simulated graph. For modifications $M\subseteq C$, we write the combined transformation as $T_M(G)$.

Threshold searches for

$$ M^*=\underset{M\subseteq C}{\operatorname{argmin}}\;|M| $$

subject to

$$ D\subseteq R_A(S;T_M(G)). $$

In words, every selected destination must become reachable while the number of interventions is minimised.

For solutions containing the same number of interventions, Threshold prefers the solution that opens the greatest total reachable area:

$$ \max\sum_{v\in R_A(S;T_M(G))}\operatorname{area}(v). $$

It then prefers the solution reaching the greatest number of nodes and uses stable modification identifiers as a deterministic final tie-breaker.

The current implementation performs an exhaustive, deterministic search over combinations of up to 15 candidate modifications. This is practical for the focused intervention sets generated by the application and guarantees that the first valid intervention count is minimal.

Challenges we ran into

The hardest part of the project was not drawing a graph—it was deciding when the evidence from a floor plan was strong enough to create one.

Turning visual detections into trustworthy connections: Raster2Seq could identify room polygons and door-like geometry, but a detected door did not automatically reveal which rooms it connected. Early versions produced disconnected rooms, self-loops, oversized regions, and visually plausible but unjustified edges. We introduced conservative door-side sampling and kept ambiguous connections for human review instead of inventing topology.
Preserving detail through a low-resolution model input: Large and dense plans lost important detail when reduced to Raster2Seq's small input size, sometimes merging several rooms into one “Undefined” region. We introduced overlapping tiled inference, source-coordinate transformation, boundary filtering, and deduplication to recover more rooms and doors without creating excessive duplicates.
Running GPU inference remotely: Raster2Seq depends on Linux, CUDA, and compiled GPU operations, but our development machines did not have NVIDIA hardware. Moving inference to RunPod introduced authentication, networking, port exposure, process-health, and cost-management problems. A running pod could still return HTTP 502 if the internal Uvicorn worker had stopped, so we added health checks and verified deployments with real external inference requests.
Distinguishing inaccessible from unknown: Floor plans often omit doorway widths, threshold heights, gradients, and turning-space measurements. Treating missing evidence as accessible would be unsafe, while treating it as blocked would be overly pessimistic. We introduced accessible, blocked, and unknown states and preserved that distinction through graph traversal, optimisation, colours, and user-facing explanations.
Converting pixels into meaningful measurements: Accessibility rules use millimetres, while detector geometry begins in pixels. We added a calibration workflow based on a user-marked known dimension, then ensured the service did not present precise doorway, clearance, or accessibility conclusions before a valid scale was established.
Making a detailed graph understandable: Displaying every room polygon, centroid, label, edge, edge label, and accessibility state at once quickly became overwhelming. We learned to keep the underlying graph detailed while progressively revealing the spatial plan, relevant accessibility paths, and technical editing information according to the user's current task.
Keeping parallel development compatible: The frontend, graph model, extraction pipeline, remote service, and shared schemas evolved simultaneously. This caused merge conflicts and compatibility failures, including a frontend expecting fields that an older backend did not return. We preserved functionality from parallel implementations, added backward-compatible response normalisation, and repeatedly ran backend tests, linting, TypeScript checks, and production builds after integration.

Accomplishments that we're proud of

We are proud that Threshold connects several difficult stages into one coherent workflow:

converting real floor plans into structured graph data;
running GPU-dependent inference without requiring users to own an NVIDIA machine;
preserving uncertainty instead of presenting AI predictions as confirmed facts;
supporting deterministic SVG parsing alongside AI-assisted raster extraction;
keeping the verified physical graph as the source of truth;
separating physical connectivity from accessibility;
producing explainable before-and-after reachability results;
finding a provably minimum intervention count within the supported candidate set;
presenting the result as an editable spatial map rather than an abstract collection of JSON objects.

Most importantly, every recommendation can be traced back to a room, physical connection, measurement, accessibility rule, and graph transformation.

What we learned

We learned that extracting geometry and understanding connectivity are different problems. Detecting two rooms and a door does not automatically prove that the door connects those rooms. Conservative geometric reasoning and human verification are essential.

We also learned that accessibility is not naturally binary when working from floor plans. Missing measurements should not silently become either accessible or inaccessible. The tri-state model allows Threshold to distinguish a confirmed barrier from something that still needs inspection.

Graph theory provided a strong abstraction because it separated three concerns:

the physical building graph;
the accessible subgraph derived from known evidence;
the proposed graph produced by simulated interventions.

This separation made the analysis easier to test, explain, and extend.

Finally, we learned that the clearest interface is not necessarily the interface that displays the most graph data at once. The underlying graph can remain detailed while the UI progressively reveals rooms, connections, barriers, and recommendations according to the user's current task.

What's next for Threshold

The next step is to improve the verification experience and make complex graphs easier to understand through progressive disclosure. A simple plan view can show rooms and physical door locations, while accessibility and technical graph layers can reveal paths, measurements, and stable edge identifiers only when needed.

We also want to:

improve room and doorway recognition across a wider variety of architectural drawings;
introduce stronger label placement and collision avoidance;
support additional floors and vertical connections;
expand the intervention library and accessibility profiles;
attach confidence and review status to individual detections;
compare alternative solutions using cost, disruption, and reachable area;
export verified graphs and accessibility reports;
evaluate extraction accuracy against a larger annotated floor-plan benchmark.

Our long-term goal is for Threshold to become a transparent decision-support tool: one that turns a difficult floor plan into an understandable model of movement, clearly distinguishes facts from uncertainty, and helps people explore the smallest changes that could make a building more accessible.