Sentry

Inspiration

Structural cracks are among the earliest warning signs of damage in bridges, columns, and walls, but inspections are still mostly manual, slow, and subjective. Existing automated tools often make things worse by being overconfident: they report a verdict on every image, even when the image shows something ambiguous like spalling (chunks of concrete breaking away) or surface texture. We wanted a tool that is honest about what it doesn't know. Sentry detects cracks, but it also knows when to say "a human should look at this."

What it does

Sentry takes a photo of a concrete surface and returns an explainable inspection result:

Detects cracks, including faint and fragmented ones
Separates true linear cracks from spalling and background noise
Reports a confidence score and a verdict: no_crack, human_review, or crack
Lets the inspector set a region of interest (ROI) and a scale reference so measurements are meaningful
Reports spall candidates separately, so wide, non-linear damage is never mislabeled as a crack

How we built it

Sentry is built on OpenCV and classical computer vision, which keeps it fast, transparent, and easy to audit, with no black-box model.

Hysteresis thresholding (97th / 93rd percentiles). A strict high threshold finds confident crack pixels, and a looser low threshold recovers faint segments, but only where they connect to a confident one.
Crack chaining with union-find. Real cracks break apart across grooves and texture, so we merge fragments into a single chain when they are close and aligned:

$$\text{merge}(a,b) \iff d(a,b) \le \texttt{gap_max_px} \;\wedge\; \Delta\theta(a,b) \le \texttt{max_angle_deg}$$

Ranking by total skeleton path length. Instead of scoring a single connected component, we rank each chain by the full length of its skeleton path, which favors long, continuous fractures over short blobs.
Spall detection. Wide, non-linear features are reported as spall_candidates. Any spall forces a human_review verdict, and confidence is capped at $0.69$.
Verdict thresholds. With confidence $c$:

$$\text{verdict} = \begin{cases} \texttt{no_crack} & c < 0.35 \ \texttt{human_review} & 0.35 \le c < 0.70 \ \texttt{crack} & c \ge 0.70 \end{cases}$$

Deployment on AWS for repeatability and observability: [add your services here, e.g. compute, storage, logging/monitoring].

A suite of 92 automated tests guards every change, so we could keep improving the algorithm without regressions.

Challenges we ran into

Crack fragmentation. A single horizontal crack crossing grooves in the surface was split into pieces, and the pieces were individually rejected as too small. Union-find chaining and path-length ranking fixed this.
Spalling vs. cracks. Spalled regions have strong edges and can look like linear cracks. Teaching the system to recognize wide, non-linear features and escalate them took several iterations.
Faint segments. A single global threshold either missed hairline cracks or flooded the result with noise. Hysteresis thresholding gave us both.
Debugging a classical pipeline. When a candidate was rejected, we needed to see why. We built a debug table and overlay image that show every candidate and the rule that rejected it.
No regressions. Every algorithm change had to keep all 92 tests passing.

What we learned

Calibrated honesty beats false confidence. A human_review verdict is a feature, not a failure.
Simple, explainable techniques (percentile hysteresis, union-find, skeleton length) can solve problems that seem to demand a heavier model.
Good debug tooling and a strong test suite make fast iteration safe.
Real-world inspection needs context, which is why ROI and scale reference inputs matter.

What's next

Real-world calibration of the scale reference to report crack length and width in physical units
Handling more surface types and lighting conditions
Batch processing of inspection photos with a report for each structure
[Add your own roadmap items]