What is Defect Gating?

Defect gating is a context-aware inference filtering strategy that suppresses predicted defect labels by evaluating their applicability to the detected surface material type and structural domain. In TarmacView, defect gating functions as a post-inference validation layer — after the computer vision model produces raw defect predictions with confidence scores, the gating logic inspects each prediction against a predefined applicability table that maps defect types to compatible surface contexts. Predictions flagged for defects that are structurally impossible or irrelevant on the given surface are suppressed before they appear in the final inspection report. This mechanism directly addresses one of the most persistent challenges in automated infrastructure inspection: false positive predictions arising from domain mismatch between training data and inference conditions.

The Problem: False Positives on Wrong Surface Types

Automated defect detection models are trained on datasets that typically contain images of specific infrastructure types — concrete bridges, asphalt roads, building facades, or runway pavements. When deployed in real-world inspection scenarios, these models encounter surface types and structural contexts that may differ from their training distribution. A deep learning model trained exclusively on reinforced concrete bridge defects will learn visual features associated with spalling (fractured concrete surfaces), efflorescence (white crystalline deposits), and exposed rebar (oxidized steel visible through broken concrete). When this same model processes an image of asphalt pavement, it may activate those same feature detectors on surface textures that visually resemble concrete defects — a rough patch of aged asphalt may trigger the spalling detector, while a light-colored aggregate particle exposed by raveling may activate the efflorescence detector.

The consequence is false positive predictions — defect labels reported on surfaces where those defects are structurally impossible. False positives in infrastructure inspection carry significant operational costs. They waste inspector time by requiring manual verification of predictions that are known to be invalid. They degrade the statistical quality of inspection reports by inflating defect counts and severity distributions. In worst-case scenarios, false positives can trigger unnecessary maintenance actions, diverting limited maintenance budgets away from genuine defects. Research published in Automation in Construction (2023) found that false positive rates in automated pavement distress detection ranged from 15% to 35% depending on the model architecture and training data composition. A separate study in the Journal of Infrastructure Systems documented that false positive suppression through domain-aware filtering improved inspection precision by over 40% compared to unfiltered model outputs.

The root cause of surface-type false positives lies in the training data paradigm. Most defect detection models are trained on single-domain datasets — a model trained on the SDNET2018 bridge deck dataset, for example, learns to associate certain texture patterns with crack labels. When that model encounters the distinctive texture of chip-seal pavement or the surface pattern of a grooved concrete runway, the learned feature detectors may fire incorrectly. The model has no intrinsic understanding that certain defect types are physically impossible on certain surfaces — it only knows pixel-to-label associations from its training distribution. Defect gating bridges this gap by injecting explicit domain knowledge as a hard constraint at inference time.

Defect Gating Logic

The defect gating logic in TarmacView operates as a deterministic filter applied after the primary inference pass. The architecture follows a three-stage pipeline: surface classification, domain inference, and label filtering.

Stage 1 — Surface Classification: For each image tile or frame in the inspection dataset, the system determines the surface material type. This can be accomplished through several methods: metadata-based classification (the inspection project explicitly defines the surface type for each asset), visual surface classification (a lightweight classifier model predicts concrete vs. asphalt from image features), or sensor fusion (combining visual data with LIDAR or spectral data for material identification). The surface classifier operates independently of the defect detection model and provides the material context required for gating decisions.

Stage 2 — Domain Inference: The structural domain context — bridge, building, pavement, runway, or concrete-generic — is determined from the asset registry, project configuration, or a dedicated domain classifier. Domain inference provides an additional layer of context beyond surface type. For example, a concrete surface could belong to a bridge deck domain, a building facade domain, or a concrete pavement domain, each with different defect applicability rules. Certain defects are relevant only within specific structural domains: joint spalling is relevant on bridge decks and concrete pavements but rarely on building facades, while efflorescence on interior building walls carries different severity implications than efflorescence on bridge substructures.

Stage 3 — Label Filtering: Each predicted defect label is looked up in the defect applicability table for the inferred surface type and domain combination. The table specifies whether each defect label is allowed, blocked, or conditional for each context. Allowed labels pass through to the final output. Blocked labels are suppressed regardless of confidence score. Conditional labels are evaluated against additional criteria — for example, crack detection on concrete surfaces may be allowed but only above a higher confidence threshold than on asphalt surfaces, where cracks are more common and visually distinct.

The mathematical formulation of the gating decision is:

g(L, S, D) = {
  1 if A(L, S, D) = allowed
  0 if A(L, S, D) = blocked
  f(C(L), T(S, D)) if A(L, S, D) = conditional
}

Where L is the defect label, S is the surface type, D is the structural domain, A is the applicability function, C(L) is the model confidence for label L, and T(S, D) is the confidence threshold for the given surface-domain combination. For conditional labels with confidence scores below the threshold, the prediction is also suppressed.

This deterministic approach ensures that gating decisions are reproducible and explainable — unlike learned filtering approaches that may introduce their own failure modes, hard-coded gating provides a guarantee that certain categories of false positives will never appear in the output.

Surface Type Classification for Gating

Surface type classification is the foundational component of the defect gating pipeline. Accurate material identification is essential because gating decisions cascade from the surface type determination — a misclassified surface renders the entire gating strategy ineffective for that tile or frame.

TarmacView supports three surface classification methods, selectable based on the available data and operational requirements:

Metadata-based classification uses pre-existing information about the inspected asset to determine surface type. Airport pavement management databases, bridge inventory systems, and building asset registries typically specify the construction materials for each element. A bridge inspection project automatically inherits the surface type classification from the bridge inventory record: concrete deck, asphalt overlay, steel girders, etc. Metadata-based classification is the most reliable method when accurate records exist, as it decouples surface classification from visual inference and eliminates classification errors at the gating input.

Visual surface classification applies a dedicated machine learning model trained to distinguish concrete, asphalt, composite, and other surface materials from image data alone. The surface classifier operates at the tile level (typically 256×256 or 512×512 pixels) and outputs a probability distribution over surface types. The classifier is trained on a diverse dataset of infrastructure surface images labeled by material type. Features used by the classifier include color distribution (concrete tends toward gray-blue, asphalt toward gray-black), texture statistics (concrete has more pronounced aggregate exposure, asphalt has more uniform binder coverage), and structural patterns (concrete joints vs. asphalt pavement seams). Visual classification achieves accuracy exceeding 95% under consistent lighting and surface conditions but degrades under challenging conditions such as wet surfaces, heavy shadows, or novel surface treatments.

Sensor fusion classification combines visual data with additional sensor modalities for robust material identification. LIDAR intensity returns differ between concrete and asphalt surfaces, providing a complementary signal independent of visual appearance. Hyperspectral imaging can distinguish material composition through spectral reflectance signatures. Thermal infrared imaging reveals thermal conductivity differences between surface materials. Sensor fusion is the most robust classification method but requires additional hardware and data processing infrastructure.

The surface type classification output feeds directly into the defect gating logic. Each tile or frame receives a surface type label — concrete, asphalt, composite, metal, or unknown — along with a classification confidence score. Tiles with classification confidence below a configurable threshold (default 0.85) default to the most conservative gating configuration, typically allowing only universal defects to avoid false positives from misclassification.

Domain Inference

Domain inference extends the gating context from surface material to structural function — the role that the inspected element serves within the infrastructure system. Domain classification is essential because the same surface material may host different defect types depending on its structural function and loading conditions.

TarmacView defines five primary structural domains for defect gating:

Bridge domain encompasses all structural elements of bridge infrastructure: deck, girders, piers, abutments, bearings, and approach slabs. Defect types relevant to the bridge domain include concrete-specific defects (spalling, efflorescence, exposed rebar, corrosion cracking), universal defects (cracks, scaling, abrasion), and bridge-specific defects (bearing displacement, joint damage, scour exposure). The bridge domain applies the most comprehensive set of defect applicability rules because bridges combine structural concrete elements subject to high cyclic loading with pavement surfaces on approach spans.

Building domain covers structural and non-structural building elements including columns, beams, slabs, walls, and foundations. Building defects emphasize concrete-specific deterioration mechanisms such as carbonation-induced corrosion, alkali-silica reaction (ASR), and freeze-thaw damage. Efflorescence on building facades is a common indicator of moisture intrusion and is prioritized in building domain gating. The building domain typically excludes pavement-specific defects such as rutting and raveling, though cracks remain universal.

Pavement domain includes road surfaces, parking areas, and general transportation pavements. The pavement domain prioritizes distress types defined by standardized pavement condition indices: ASTM D5340 for airport pavements and ASTM D6433 for roads and parking lots. Defect labels in the pavement domain include raveling, bleeding, rutting, shoving, weathering, and cracking of all types (longitudinal, transverse, block, alligator). Concrete-specific structural defects (spalling, exposed rebar) are blocked in the pavement domain unless the pavement is explicitly classified as concrete pavement, in which case joint spalling and corner breaks are permitted.

Runway domain applies specifically to airfield pavements under ICAO Annex 14 and FAA Advisory Circular standards. Runway gating is the most restrictive because the safety-critical nature of airfield operations demands minimal false positive rates. Defect labels in the runway domain include surface distress types that affect friction characteristics, FOD generation potential, and load-bearing capacity. Runway-specific defects such as rubber deposit accumulation, fuel spill damage, and jet blast erosion are permitted only in this domain. Concrete-specific structural defects are permitted only on runway sections classified as concrete pavement (typically high-load areas such as runway ends and intersections).

Concrete-generic domain serves as a fallback for concrete structures that do not fit into the bridge, building, or dedicated pavement categories. This includes retaining walls, culverts, drainage channels, noise barriers, and marine structures. The concrete-generic domain permits all concrete-specific and universal defects but excludes domain-specific defects that require specialized structural context.

Domain inference can be performed through several channels: asset registry lookup (most reliable), project configuration (user-specified at inspection setup), visual domain classifier (based on structural form and context features), or GPS coordinate cross-reference with geospatial infrastructure databases (bridges, buildings, and pavements are typically mapped in separate GIS layers).

Defect Label Applicability Tables

The defect label applicability table is the operational core of the gating system. Each row in the table specifies a defect label, the surface types on which it is permitted, the structural domains in which it is relevant, and any conditional rules that modify the gating behavior.

The applicability table is configurable at the project level in TarmacView. Users can modify the allowed/blocked/conditional assignments for each defect label based on their specific inspection requirements and local knowledge of the infrastructure being inspected. A bridge inspection project in a region with steel girder bridges, for example, may add metal-specific defect labels to the gating table. An airport pavement inspection project may configure the gating to permit concrete-specific defects only on runway sections known to have concrete pavement while blocking them on asphalt runway sections.

Conditional entries in the table trigger secondary evaluation rules. For example, cracking on concrete surfaces may be conditional on minimum crack width (only cracks wider than 0.3 mm are reported), while cracking on asphalt surfaces may be conditional on crack pattern (only alligator cracking in load zones is reported). These conditional rules add a second layer of domain-specific validation beyond the surface type check.

Concrete-Specific vs Universal Defects

The distinction between concrete-specific and universal defects is fundamental to the gating architecture. Concrete-specific defects arise from deterioration mechanisms that are unique to concrete as a construction material — corrosion of embedded steel reinforcement, alkali-aggregate reactions, carbonation-induced degradation, and freeze-thaw damage that produces characteristic spalling and scaling patterns. These defects are structurally impossible on asphalt surfaces, where the deterioration mechanisms are entirely different: binder oxidation, aggregate stripping, and permanent deformation under traffic loading.

Concrete-specific defects that are blocked on non-concrete surfaces include:

Spalling is the fracture and displacement of surface concrete caused by internal stresses — most commonly from corrosion expansion of embedded reinforcement bars. Corrosion products (iron oxides and hydroxides) occupy up to six times the volume of the original steel, generating tensile stresses that exceed the concrete tensile strength. The resulting spall exposes the reinforcement to further corrosion and accelerates the deterioration cycle. Spalling is reported in severity grades defined by ASTM D5340: low (less than 1 inch depth), medium (1–2 inches), and high (greater than 2 inches). The gating logic permits spalling predictions only on concrete surfaces within bridge, building, and concrete-generic domains.

Efflorescence is the deposition of white, crystalline salts on concrete surfaces formed when water dissolves soluble salts from within the concrete matrix and deposits them on the surface through evaporation. Efflorescence itself is not structurally damaging, but it is a critical indicator of moisture migration through the concrete, which can transport chlorides to reinforcement and accelerate corrosion. Efflorescence detection is permitted exclusively on concrete surfaces and is most significant in bridge and building domains where moisture intrusion has structural implications.

Exposed rebar refers to reinforcement steel that has become visibly exposed due to spalling, abrasion, or construction defects. Exposed rebar represents a structural safety hazard because the exposed section is actively corroding and the remaining reinforcement cross-section may be inadequate for design loads. The defect gating logic permits exposed rebar predictions only on concrete surfaces, as reinforcement bars are not present in asphalt or other surface materials. The presence of exposed rebar in the output triggers an automatic severity escalation in the inspection report.

Corrosion as a defect label encompasses rust staining, corrosion-induced cracking patterns, and visible corrosion products on concrete surfaces. Corrosion on concrete surfaces manifests as orange-brown staining along rebar paths, rust-colored runoff from exposed reinforcement, and crack patterns that follow the reinforcement layout. These visual signatures are distinct from any possible defect on asphalt surfaces, making corrosion predictions on asphalt almost certain false positives.

Universal defects that are permitted across all surface types and domains include:

Cracking appears on all infrastructure surfaces and is the most universally applicable defect label. The gating logic permits cracking predictions on concrete, asphalt, metal, and composite surfaces within any domain. However, the crack classification may differ by context — a crack on a concrete bridge deck may be classified as structural or non-structural based on width and pattern, while a crack on an asphalt pavement is classified by type (fatigue, block, edge, reflective) per ASTM distress identification standards.

Weathering encompasses surface deterioration from environmental exposure — UV radiation, temperature cycling, moisture, and chemical attack. On concrete, weathering manifests as surface mortar loss and aggregate exposure. On asphalt, weathering appears as binder embrittlement and surface cracking. The weathering label is universally permitted, though the severity assessment criteria differ by surface type.

Scaling is the flaking or peeling of surface material in discrete areas. On concrete, scaling typically results from freeze-thaw cycling or chemical attack. On asphalt, scaling-like patterns may result from stripping or binder failure. The gating logic permits scaling on concrete and asphalt surfaces but blocks it on metal surfaces where the equivalent defect would be classified as corrosion or coating failure.

Tile-Level vs Frame-Level Prediction Gating

The granularity at which gating is applied has significant implications for both precision and computational efficiency. TarmacView supports two gating modes: tile-level gating and frame-level gating.

Tile-level gating applies the defect applicability filtering independently to each image tile — a small cropped region of the full inspection frame, typically 256×256 or 512×512 pixels. Each tile is individually classified for surface type, and the defect predictions within that tile are filtered according to the tile’s surface type. Tile-level gating is essential for assets with heterogeneous surface composition. A bridge with concrete deck, asphalt approach spans, and steel railings will have tiles covering each surface type. Without tile-level gating, a concrete-specific defect predicted on an asphalt approach tile would appear in the output as a false positive. With tile-level gating, the asphalt tile receives asphalt-appropriate gating rules and the concrete-specific prediction is suppressed.

Tile-level gating introduces additional computational overhead because surface classification must be performed for each tile independently. However, the surface classifier is a lightweight model — typically a MobileNet or EfficientNet variant with fewer than 10 million parameters — that adds minimal latency compared to the primary defect detection model. TarmacView benchmarks show that tile-level gating adds approximately 8–12% to total inference time on GPU-accelerated processing pipelines while reducing false positive rates by 60–75% on heterogeneous assets.

Frame-level gating applies a single surface type and domain classification to the entire inspection frame and filters all defect predictions within that frame uniformly. Frame-level gating is appropriate for assets with homogeneous surface composition — an entire runway pavement section, a building facade, or a bridge girder made entirely of one material. The computational savings are substantial: surface classification is performed once per frame rather than once per tile, reducing the gating overhead to approximately 2–4% of total inference time.

The choice between tile-level and frame-level gating is configured at the project level in TarmacView. The recommended default is tile-level gating for all inspection projects, with frame-level gating reserved for projects where the asset surface composition is verified to be homogeneous and the computational efficiency gain is operationally significant. A fallback mechanism automatically switches misclassified tiles to the most conservative gating configuration to maintain robustness.

Multi-resolution gating is an advanced mode that applies tile-level gating at the native resolution of the defect detection model while aggregating surface classifications across multiple tiles for domain inference at the frame level. This hybrid approach combines the precision of tile-level material assignment with the robustness of frame-level structural domain classification, providing the best of both gating modes.

Concrete-Specific vs Asphalt-Specific Defects

The gating symmetry between concrete and asphalt surfaces is a critical design principle. Just as concrete-specific defects are blocked on asphalt surfaces, asphalt-specific defects are equally blocked on concrete surfaces. This bidirectional gating ensures the system does not produce false positives in either direction.

Asphalt-specific defects that are blocked on non-asphalt surfaces include:

Bleeding is the upward migration of asphalt binder to the pavement surface, forming a shiny, reflective film. Bleeding occurs when the binder content is excessive, the pavement is over-compacted, or high temperatures cause binder expansion. On concrete surfaces, there is no binder material to migrate, making bleeding detection impossible. Any model prediction of bleeding on a concrete surface is a guaranteed false positive caused by the model misinterpreting surface moisture or sealer as binder film.

Rutting is permanent deformation in the wheel paths caused by consolidation or shear failure of the asphalt pavement structure. Rutting produces longitudinal depressions that collect water and reduce pavement serviceability. Concrete pavements do not rut — they may fault, spall, or crack under traffic, but the deformation mechanism is fundamentally different. Rutting predictions on concrete surfaces are suppressed by the gating logic.

Raveling is the progressive dislodgement of aggregate particles from the asphalt surface due to binder aging or stripping. Concrete surfaces may exhibit aggregate exposure through weathering or scaling, but the mechanism is distinct from asphalt raveling. The gating logic distinguishes between weathering (universal) and raveling (asphalt-specific) based on the surface type classification.

Shoving is the longitudinal displacement of asphalt pavement material, typically at intersections or other areas of high shear loading. Shoving creates waves or corrugations in the pavement surface. Concrete surfaces do not exhibit shoving — they may exhibit faulting or slab displacement at joints, but the failure mode is distinct. The gating logic blocks shoving predictions on concrete surfaces.

Disabling Gating (–no-defect-gating)

TarmacView provides a –no-defect-gating command-line flag and equivalent API parameter that disables all gating logic and outputs raw model predictions without any surface type or domain filtering. This capability supports several operational scenarios:

Model debugging and validation — when developing or fine-tuning defect detection models, researchers need to examine all model outputs including predictions on incompatible surface types. Disabling gating reveals the model’s behavior across all contexts, enabling identification of systematic false positive patterns that can be addressed through training data augmentation or model architecture improvements. Model validation metrics computed with gating enabled would be artificially inflated because gating suppresses known false positives — validation teams should compute precision and recall both with and without gating to understand the model’s intrinsic performance versus the system’s delivered performance.

Training data quality assessment — inspection of raw model predictions with gating disabled can reveal mislabeled training data. If a model consistently predicts spalling on asphalt surfaces in the training dataset, the source images may have been mislabeled — perhaps an asphalt patch on a concrete surface was labeled as concrete, or the training annotation assigned a concrete-specific defect label to an image of a composite or coated surface. These data quality issues would be masked by gating in production but are exposed when gating is disabled.

Unknown or mixed surface types — when the surface type cannot be reliably determined by any available classification method, the safest configuration may be to disable gating entirely and present all model predictions for human review rather than risk blocking a genuine defect through incorrect surface classification. The –no-defect-gating mode is recommended for inspection projects where assets have novel surfaces, experimental materials, or composite surface treatments that the surface classifier has not been trained to recognize.

Cross-domain research — researchers studying defect characteristics across different infrastructure types benefit from unfiltered outputs that show how the same defect label manifests on different surfaces. For example, comparing crack morphology on concrete bridge decks versus asphalt pavements requires access to predictions on both surface types without filtering.

When gating is disabled, all predictions from the model are included in the output alongside the surface type classification for reference. A metadata field in the prediction output indicates that gating was disabled, allowing downstream processing pipelines to apply their own filtering or to flag the predictions for manual review. The recommendation in TarmacView documentation is to enable gating for all production inspection runs and to disable gating only for the specific use cases described above, with the understanding that raw model outputs will contain significantly more false positives than gated outputs.

Impact on Precision and Recall

The introduction of defect gating produces a measurable shift in the precision-recall balance of the automated inspection system. Understanding these trade-offs is essential for configuring gating appropriately for different operational contexts.

Precision improvement is the primary benefit of defect gating. Precision — the fraction of predicted positive labels that correspond to actual defects — increases because the suppression of known-impossible defect categories reduces the denominator of the precision calculation without affecting the numerator (genuine positive detections). In TarmacView field deployments, defect gating has achieved precision improvements ranging from 35% to 55% across different asset types and surface compositions. Concrete bridge inspections show the largest precision gains (45–55%) because the number of concrete-specific defect labels that can fire on non-concrete tiles is largest in heterogeneous bridge assets. Runway pavement inspections show more modest precision gains (20–30%) because the surface composition is typically more homogeneous.

Recall reduction is the potential cost of defect gating. Recall — the fraction of actual defects that are correctly identified by the system — may decrease if the gating configuration incorrectly blocks valid defect predictions. This can occur through two mechanisms: surface type misclassification (a concrete tile misclassified as asphalt causing concrete-specific defects to be blocked), or overly restrictive domain configuration (a concrete-generic structure assigned to the pavement domain where concrete-specific defects are blocked). In practice, recall reduction from gating is typically 2–5% in well-configured systems, substantially smaller than the precision gains.

The F1 score — the harmonic mean of precision and recall — improves by 15–25% in typical TarmacView deployments with defect gating enabled, reflecting the net positive impact of false positive suppression despite the minor recall cost.

Note: Ranges reflect observed performance across different asset types, surface compositions, and model architectures in TarmacView field deployments.

Precision-recall curves with and without gating show the systematic shift toward higher precision across all confidence thresholds. The curve with gating enabled lies above and to the right of the curve without gating, indicating that for any given recall level, the system achieves higher precision when gating is active. The area under the precision-recall curve (AUC-PR) increases by 12–20 percentage points with gating enabled.

The operational significance of these metric improvements is substantial. A precision of 0.85 means that 85 out of every 100 defect predictions in the inspection report correspond to genuine defects, compared to only 60 out of 100 without gating. This translates directly to reduced inspector verification time — fewer false positives to manually review and reject — and higher confidence in the inspection data quality for maintenance planning decisions.

Future: Learned Gating

The current generation of defect gating uses hard-coded applicability tables with deterministic allow/block/conditional rules. This approach provides reliability, explainability, and guaranteed false positive suppression for well-understood defect-surface relationships. However, it has limitations: it cannot adapt to novel surface materials or defect types without manual configuration updates, it cannot handle ambiguous cases where surface type is uncertain, and it cannot learn from operational feedback to improve its filtering decisions over time.

Learned gating represents the next evolution of the gating architecture. Instead of hard-coded rules, a learned gating network predicts defect applicability directly from visual features and contextual metadata. The gating network is trained on a dataset of defect predictions paired with human-provided feedback on their applicability — crowdsourced from inspectors who review and accept or reject defect predictions during their normal workflow. Over time, the gating model learns to distinguish applicable from inapplicable defect predictions with increasing accuracy, including for novel defect-surface combinations that were not present in the initial rule set.

The learned gating architecture integrates with the primary defect detection model through a shared feature backbone. The first stages of the neural network extract general-purpose visual features from the input image. These features are then routed to two parallel heads: the defect detection head (predicting defect labels, bounding boxes, and confidence scores) and the gating head (predicting applicability scores for each defect label given the visual and contextual features). The gating head output is a vector of applicability probabilities — one per defect label — that modulate the final prediction output. A gating probability below 0.5 suppresses the prediction regardless of the detection head’s confidence score.

Probabilistic gating extends the learned gating concept by replacing binary allow/block decisions with continuous applicability scores. Instead of a hard suppression threshold, probabilistic gating produces a gating confidence that is multiplied by the detection confidence to produce a final confidence score. This allows the system to handle uncertainty — a defect on a surface that is 70% likely to be concrete and 30% likely to be asphalt receives a gating score of 0.70 for concrete-specific defects, reducing their confidence rather than blocking them entirely. The final prediction carries a combined confidence that reflects both detection certainty and contextual applicability.

Adaptive gating adjusts gating thresholds based on operational risk profiles. A high-risk inspection scenario — an airport runway with active flight operations, or a bridge with known structural deficiencies — may adopt conservative gating thresholds that prioritize precision over recall, accepting higher false negative risk to minimize false positive disruptions. A low-risk inspection scenario — a routine pavement survey on a low-traffic road — may adopt permissive gating thresholds that prioritize recall over precision, accepting more false positives to ensure no genuine defects are missed. The adaptive gating framework allows the system to tune its behavior to the operational context without manual reconfiguration.

Online learning for gating enables the gating model to improve continuously through operational feedback. When an inspector accepts or rejects a prediction in the TarmacView review interface, that feedback is recorded and used to update the gating model. Over time, the system learns which defect predictions on which surface and domain combinations are most likely to be applicable, converging toward optimal gating behavior for each specific asset type and inspection environment. Online learning requires careful safeguards to prevent feedback loops — a rejected true positive could bias the gating model toward blocking valid predictions in the future — but when properly implemented, it enables continuous improvement without the need for periodic model retraining cycles.

Conclusion

Defect gating is a critical inference strategy for automated infrastructure inspection systems operating across heterogeneous surface types and structural domains. By filtering predicted defect labels based on surface material type, structural domain, and defect applicability rules, the gating logic suppresses false positive predictions that would otherwise degrade inspection quality and operational confidence. The concrete-specific defects that define structural deterioration — spalling, efflorescence, exposed rebar, and corrosion — are physically impossible on asphalt surfaces and would appear as false positives if the system reported them there. The gating logic prevents these errors by enforcing domain knowledge as a hard constraint at inference time, ensuring that defect predictions are always contextually appropriate for the surface on which they are reported.

The implementation of defect gating in TarmacView spans surface type classification, structural domain inference, defect applicability tables, and configurable gating granularity from tile-level to frame-level filtering. The precision improvements from gating are substantial — 35–55% in typical deployments — while the recall reduction is minimal at 2–5%. The system supports disabling gating for model debugging, training validation, and unknown-surface scenarios through the –no-defect-gating flag. Future development toward learned, probabilistic, and adaptive gating will extend these capabilities to handle novel surface materials, uncertain classification conditions, and operationally tuned precision-recall trade-offs.

For infrastructure asset managers, the practical significance of defect gating is clear: inspection reports that contain fewer false positives require less manual verification time, produce higher quality data for maintenance prioritization, and generate greater trust in the automated inspection system. As automated defect detection becomes more widely adopted across the infrastructure sector, context-aware gating strategies will be essential for delivering inspection results that are both accurate and operationally useful.