LATUS Fiberproof AI

Fiber quality, fully verified. In days rather than months.

The AI platform for automated image and document review across the FTTH rollout. 100% inspection instead of a 20% sample. What used to take a year of manual work is now done in a week.

Request live demo Understand the solution

100% full inspectioninstead of sampling

>99% confidencein image recognition

100k+ documentsin a few days

52 to 1 weekstime saved per construction lot

What is Fiberproof AI

One platform that automatically reviews every photo and every document from the fiber rollout.

Fiberproof AI combines computer vision, deep learning and rule-based validations to turn photos, measurement protocols and construction records into actionable quality findings - complete, auditable, GDPR-compliant.

Instead of sampling there is end-to-end inspection of every home connection. Instead of manually compiled weekly reports, network operators, subsidy bodies and general contractors receive clear findings on construction quality within days.

The solution is specialised for FTTH rollout: APL detection, building-entry classification, walk-through protocol analysis, OTDR processing. Not a generalist AI - domain knowledge is built directly into the models.

21,8Mio

FTTH/FTTB households in Germany (end of 2024) - trend: 39.3 million by 2030.

~400Mio

documents that will be produced in Germany by 2030 - 10 per home connection.

125/h

address objects processed per hour, ≤ 5 seconds per individual check.

Use cases

Three scenarios, three clear outcomes.

From real LATUS project experience. The figures come from documented pilot projects; open items from the Solution Description are deliberately not presented here as hard facts.

Carrier . Network operator

Invoice release in one week instead of one year

More than 100,000 documents for one construction lot. Manual sampling (20%) typically takes a year - including coordination, follow-up requests and alignment.

Outcome: 100% full inspection in one week. 98% time saved. Audit trail for every inspection decision.

Subsidies . Compliance

Subsidy evidence instead of a project showstopper

Missing or incomplete documentation can lead to subsidies not being paid out - not a mere risk, but a documented project stopper.

Outcome: Automated completeness evidence. Audit-grade documentation per home connection.

General contractor

Catch defects early, not expensively late

Defects detected late in the construction lot mean rework, payment delays and disputes between general contractor and subcontractor. Real-time inspection prevents that.

Outcome: Early detection during the construction phase. Reduced rework. Faster acceptance.

Platform modules

A modular platform. Preflight configures your use case.

Fiberproof AI is a strictly modular SaaS platform. Four core modules run at platform level: Intake, Pre-Validation, Preflight and Reporting. They form the end-to-end frame in which the atomic detection modules do their work. In Preflight you assemble the right module combination for your use case - from the full module marketplace below.

1. Intake

Multi-format upload from all relevant sources, with automatic integrity check.

2. Pre-Validation

Pre-validation sorts, classifies and flags - instead of silently discarding.

3. Preflight - the configurator

This is where you assemble the right module combination from the marketplace for your use case.

4. Reporting and output

Three standard reports plus audit trail for subsidy evidence.

Inspection process

The complete seven-step inspection process - from photo to evidence-grade report.

Modular SaaS platform, AWS multi-layered security, infrastructure as code. Each stage as its own service. Scales horizontally by load and use case.

File upload

Web drag-and-drop, SharePoint, S3, API. Multi-format: JPG, PNG, PDF (digital and scanned), Excel, OTDR-SOR.

Document recognition

Classification by document type, PDF content extraction, duplicate check both global and folder-local.

Qualitative inspection

AI image review: APL detection (open/closed/covered, Multibox), building-entry classification, trench photos, splice trays.

Measurement-value check

OTDR-SOR verification against target values, automatic attenuation and reflection analysis, fibre-endpoint check.

Renaming and sorting

Content-linked file renaming, automatic re-sorting into structured folders, search function with metadata.

Defect tables

Structured defect lists for general-contractor follow-up deliveries, confidence values per finding, unique link back to the original file.

Report and analysis

Processing Summary, Operations Summary, Result CSV. Evaluation, interpretation, audit trail for subsidy evidence.

Feature demos

What the AI actually does.

Four productive feature blocks. Click a tab for details; each function with concrete model capabilities and source references.

APL detection with confidence values

The subscriber termination point (APL) is the central inspection object of every construction acceptance. The model distinguishes states with documented detection confidence per object.

APL status: open / closed / covered
Multibox APL: open / closed
Green plugin: internal / external
Vertical black rectangle, APL bottom recognition
Confidence value (0-100%) for every detected object

Model boundary: the AI models are highly specialised for FTTH components and deliver very high precision in this context. New use cases require new training with at least 250 high-quality images per detection pattern.

Building-entry classification (HZF)

Verification of correct cable routing at the building entry - inside and outside, covered or uncovered. Direct mapping to typical carrier construction-acceptance criteria.

Inside cable: rounded covered / not covered
Outside cable: covered / not covered
Multi-object detection per image
Image cropping to defined coordinates

Data formats: JPEG, PNG. Minimum requirement per new detection pattern: 250 high-quality training images. Industry benchmark: Orange France labelled 80,000 photos in three months.

Document extraction and classification

Walk-through protocols, splice reports, construction records. Text extraction from digital and scanned PDFs, structured data from free text with the help of LLMs.

OCR for scanned documents
Text extraction from digital PDFs
Structured extraction via large language model
Order number and address extraction from walk-through protocols
OTDR-SOR parsing for measurement-protocol verification

Roadmap note: extended signature detection, handwriting OCR and context-based PII anonymisation are being added modularly. Concrete availability is agreed per project.

Reporting, auto-sorting, audit trail

The actual value proposition: thousands of chaotic files become a structured list with clear findings - which home connection, which inspection point, which result, which source.

CSV reports and Excel exports
Prediction summaries (all detected objects)
Processing summary (success / errors / time)
Automatic file renaming linked to content
Re-sorting into structured folders
Separation of duplicates and irrelevant images

Note: defect lists and invoice-release recommendations are derived in a structured way from the AI reports. Fully automated dashboards can be added modularly and are configured per project during onboarding.

Pre-Validation

The fast track into automatic document control.

Before any AI inspection makes sense, you have to know what was delivered - and whether it is complete, consistent and free of duplicates. In practice this preliminary check is a stand-alone work step with measurable value - and with Fiberproof AI you can use it as a stand-alone module.

Quantity audit by data type

Per home connection and project folder, we count how many JPEG images, PDF documents and OTDR-SOR measurement files were delivered. Actuals are compared against target specifications (e.g. an Excel attachment).

Metadata presence check

Every image file is checked for the presence of geo data (EXIF GPS). The result column "Geodata Present" (Yes/No) shows immediately which images are suitable for later address mapping.

Cross-address duplicate detection

File duplicates are explicitly detected across address boundaries. If the same file appears in two home-connection folders, the report flags this clearly - with references to all locations. This may be a technical coincidence or a fraud indicator. You see it and decide.

Pre-validation report

The result is available as a CSV directly in the application's Datasets area as "Download Report" - without taking a detour through e-mail or cloud storage.

Pre-validate only - the toggle

Pre-Validation can be used as a pure audit stage. Enable the "Pre-validate only" switch on upload and the system stops after pre-validation. You receive the pre-validation report; the dataset is retained for later AI runs. No re-upload required if you later want to apply the full pipeline - just disable the toggle and start a run from the existing dataset. The pre-validation report is generated in both cases.

Deployment scenarios

Incoming inspection at network operatorsCompleteness and duplicate check before manual sampling or further technical review.

Subsidy pre-auditQuantity and completeness evidence per home connection before filing the application with the subsidy body.

Supplier briefing at the general contractorConcrete delivery-deficit list per subcontractor and home connection, without AI content evaluation.

Fraud indicatorCross-address duplicates are a concrete, legally usable audit finding.

Function inventory

Every module in detail. Click opens the function in depth.

Behind every click is the full functional description: purpose, inputs, processing, results and typical deployment scenarios. At a glance you see what a function delivers - and where it fits into your order and quality process.

Proven in customer projects: The detection modules are trained on productive customer projects covering different component variants, labelling systems and protocol templates. Training data covers APL variants, building-distributor models and splice-tray form factors from several network operators, as well as the laser-warning variant family across all hardware components.

Platform modules 4

Intake (upload)

Purpose: Structured ingestion of data packages (images, protocols, measurement data) into the processing pipeline. Validation of folder structure and SDI/address keys.
Input: ZIP/folder structure with JPG/JPEG images, PDF protocols, SOR measurement files; optionally via UI upload or S3 sync.
Output: Dataset object with building/apartment/cellar hierarchy, unique dataset ID, asset inventory.
Use-case examples: Upload of a construction lot by a civil-engineering subcontractor; bulk import of a carrier inventory via S3.
Status: Production

Pre-Validation

Purpose: Structured data-quality check before any AI processing. Detects file types, duplicates (file hash, not file name) and geo-data presence. Prevents downstream costs from unusable data packages.
Input: Dataset from intake.
Output: PDF summary report, CSV reports (general, directory-duplicates, dataset-duplicates), ZIP package; columns EXIF-Present / GPS-Present per image; "Pre-validate only" flag possible (dataset is excluded from the run interface).
Use-case examples: Audit of a dataset before placing an order; detecting cross-address duplicates as a fraud indicator.
Status: Production

Preflight (configurator)

Purpose: Customer-driven, use-case-specific module selection. Maps which atomic detection and validation modules are enabled for a specific assignment, which thresholds apply and which CSV columns appear in the output. Core of the modularity: a specific assignment is composed here from more than 50 atomic modules.
Input: Assignment type, carrier/developer profile, desired use-case composition (e.g. NE4, GEO, LAS, BEP, document compliance), customer-specific thresholds, language variant.
Output: Run configuration (module list, thresholds, routing rules), saved profile for reuse.
Use-case examples: A carrier configures "NE4 acceptance" with Gf-GV, Gf-TA and splice-tray modules; a developer configures "BEP mass inspection" with BEP and black-cable modules; a forensic tenant configures "data-integrity audit" with only Pre-Validation and cross-validation modules.
Status: Production

Reporting

Purpose: Consolidated output of atomic module results in CSV/Excel. Structured by building/apartment/address. Optionally as a ZIP package including PDF summary.
Input: Module outputs (boolean fields, confidence scores, OCR strings, geo addresses).
Output: CSV/Excel with columns per module, value-add columns (cross-address duplicates, uniqueness flags), PDF summary, optional GIS integration.
Use-case examples: Excel report for client sign-off; CSV import into a downstream RIMO system.
Status: Production

APL family (subscriber termination point) 11

APL closed

Purpose: Detects the presence of an APL in closed state on an installation image.
Input: JPG/JPEG image.
Output: Boolean (APL closed detected: yes/no), confidence score, bounding-box coordinates.
Use-case examples: Acceptance of a regularly closed home-connection installation; check of closure discipline at the end of a construction phase.
Status: Production

APL open

Purpose: Detects an opened APL with the internal cabling visible.
Input: JPG/JPEG image.
Output: Boolean (APL open detected: yes/no), confidence score, bounding box.
Use-case examples: Splice documentation audit; prerequisite for downstream open-pattern modules.
Status: Production

APL covered

Purpose: Detects a covered/clad APL (e.g. with a protective cap or built-in front).
Input: JPG/JPEG image.
Output: Boolean (APL covered: yes/no), confidence score.
Use-case examples: Documentation of customer-grade final assembly; differentiation between assembled and factory-closed state.
Status: Production

APL Multibox closed

Purpose: Detects a multi-APL (Multibox / Gf-GV) in closed state.
Input: JPG/JPEG image.
Output: Boolean (Multibox closed: yes/no), confidence score.
Use-case examples: Acceptance of multi-tenant floor supply in an apartment building.
Status: Production

APL Multibox open

Purpose: Detects a multi-APL (Multibox / Gf-GV) in opened state.
Input: JPG/JPEG image.
Output: Boolean (Multibox open: yes/no), confidence score.
Use-case examples: Splice and distributor documentation; prerequisite for connector-counting and fibre-colour modules.
Status: Production

APL open pattern: vertical black rectangle

Purpose: Detects the vertical black rectangle (built-in splice area) inside the opened APL as an indicator of a correctly installed splice component.
Input: JPG/JPEG image of an opened APL.
Output: Boolean, confidence score.
Use-case examples: Detailed splice-installation inspection.
Status: Production

APL open pattern: green plugin internal

Purpose: Detects a green connector inside the opened APL.
Input: JPG/JPEG image of an opened APL.
Output: Boolean, confidence score.
Use-case examples: Verifies that the factory-intended connection variant was chosen.
Status: Production

APL open pattern: green plugin external upper

Purpose: Detects a green connector on the upper outside of the opened APL.
Input: JPG/JPEG image.
Output: Boolean, confidence score.
Use-case examples: Differentiation between different carrier variants of APL fitting.
Status: Production

APL open pattern: green plugin external bottom

Purpose: Detects a green connector on the lower outside of the opened APL.
Input: JPG/JPEG image.
Output: Boolean, confidence score.
Use-case examples: Differentiation between different carrier variants of APL fitting.
Status: Production

APL open pattern: pigtail

Purpose: Detects a pigtail (pre-assembled fibre end with connector) in the opened APL.
Input: JPG/JPEG image.
Output: Boolean, confidence score.
Use-case examples: Evidence of correctly prepared connection fibres in the final assembly.
Status: Production

APL open pattern: horizontal black rectangle

Purpose: Detects the horizontal black rectangle (alternative splice installation orientation) in the opened APL.
Input: JPG/JPEG image.
Output: Boolean, confidence score.
Use-case examples: Detail audit for splice-orientation conformity across different APL manufacturers.
Status: Production

Building-entry family (HZF) 6

Inside entry covered

Purpose: Detects a covered inner building entry (inside wall) on an image.
Input: JPG/JPEG image.
Output: Boolean (inside entry covered: yes/no), confidence score.
Use-case examples: Acceptance of the construction work at the outside/inside handover; check of the structural final acceptance.
Status: Production

Inside entry connection cable

Purpose: Detects the presence of a connection cable at the inner building entry.
Input: JPG/JPEG image.
Output: Boolean, confidence score.
Use-case examples: Evidence that the inner building entry is in fact continued by cable.
Status: Production

Outside entry covered

Purpose: Detects a covered outer building entry (outside wall) on an image.
Input: JPG/JPEG image.
Output: Boolean, confidence score.
Use-case examples: Weatherproofing audit; construction-progress evidence.
Status: Production

Outside entry connection cable

Purpose: Detects the presence of a connection cable at the outer building entry.
Input: JPG/JPEG image.
Output: Boolean, confidence score.
Use-case examples: Evidence that the outer entry carries a cable and does not end empty.
Status: Production

Other outside entry

Purpose: Detects alternative or atypical outer building entries that do not match the standard patterns (e.g. chimney, garage or outbuilding entries).
Input: JPG/JPEG image.
Output: Boolean, confidence score, variant class.
Use-case examples: Special-case detection in heterogeneous building stock.
Status: Production

In-house installation

Purpose: Detects an in-house installation as overall context (stairwell, basement, transition from the home connection to the apartment).
Input: JPG/JPEG image.
Output: Boolean, confidence score, context class.
Use-case examples: Routing of images into the NE4 pipeline branch; differentiation from outdoor shots.
Status: Production

Use-case compositions 5

LAS - laser safety validation

Composition: Pre-classifier + APL family (APL closed / APL open / Multibox closed / Multibox open) + Gf-TA family + laser warning sticker + laser warning embossed marking + reporting.
Purpose: Mandatory audit of laser-warning labelling on all visible devices against occupational-safety and carrier standards.
Status: Production

GEO - geo enrichment

Composition: EXIF GPS presence check + provider-agnostic geocoding + address structuring + geo-referencing of inspection results + optional GIS integration.
Purpose: Enrichment of every image and module output with a canonical postal address and a map-ready coordinate.
Status: Production

NE4 - network layer 4 in-house audit

Composition: Pre-classifier + APL family (closed/open) + Multibox family + building-entry family + Gf-GV family + Gf-TA family + splice-tray family + ONT family + cable/components family + measurement-protocol detection + acceptance-protocol detection + apartment-number extraction + Home-ID extraction + Gf-TA apartment-number uniqueness + Gf-TA HomeID uniqueness + reporting.
Purpose: Full acceptance inspection of an in-house fibre installation from the home connection to the active ONT.
Status: Production

Document compliance - construction-record completeness

Composition: Pre-Validation + acceptance-protocol detection + measurement-protocol detection + order-number extraction + address extraction from protocol + signature presence detection + signature content OCR + handwriting OCR + reporting.
Purpose: Audit of the documentary completeness of a construction record; threshold for payment release.
Status: Production

Forensic mass inspection

Composition: Intake + Pre-Validation + EXIF GPS presence check + provider-agnostic geocoding + image-vs-protocol consistency + predictive analytics for defect clustering + reporting.
Purpose: Detection of systematic errors, cross-address duplicates, fraud indicators and construction-execution anomalies across large construction-lot inventories.
Status: Production

Gf-GV family (building distribution point) 5

Gf-GV open - cabling

Purpose: Detects the visible cabling inside the opened building-distribution point.
Input: JPG/JPEG image of the opened Gf-GV.
Output: Boolean (cabling detectable: yes/no), confidence score.
Use-case examples: Acceptance of the floor installation in apartment buildings.
Status: Production

Gf-GV open - fibre colours

Purpose: Detects defined fibre colours (red/green as the primary pair) inside the opened Gf-GV and validates their presence.
Input: JPG/JPEG image of the opened Gf-GV.
Output: Boolean (red AND green detected -> TRUE), confidence score, list of detected colours.
Use-case examples: Colour-code conformity check against manufacturer specification.
Status: Production

Gf-GV closed - lock

Purpose: Detects the presence of a lock on the closed Gf-GV.
Input: JPG/JPEG image.
Output: Boolean (lock present: yes/no), confidence score.
Use-case examples: Anti-theft/anti-tamper audit; compliance with security standards.
Status: Production

Gf-GV closed - warning label

Purpose: Detects the presence of a warning sticker or sign on the closed Gf-GV.
Input: JPG/JPEG image.
Output: Boolean (warning label present: yes/no), confidence score.
Use-case examples: Mandatory labelling per carrier / network-operator standard.
Status: Production

Gf-GV closed - protective conduit

Purpose: Detects the presence of a protective conduit at the transition into the closed Gf-GV.
Input: JPG/JPEG image.
Output: Boolean, confidence score.
Use-case examples: Building-physics audit; strain-relief conformity.
Status: Production

Gf-TA family (subscriber connection) 3

Gf-TA logo uniqueness

Purpose: Detects the manufacturer logo (e.g. Genexis) on the Gf-TA device and validates the required manufacturer variant.
Input: JPG/JPEG image of the Gf-TA.
Output: Boolean (logo detected: yes/no), confidence score, manufacturer name if recognised.
Use-case examples: Incoming-goods inspection of the installed subscriber connection; vendor compliance.
Status: Production

Gf-TA apartment-number uniqueness

Purpose: Validates that the apartment number (App. No.) extracted via OCR is assigned only once per building/address.
Input: OCR result of the apartment number from the Gf-TA image + address context.
Output: Boolean (duplicate: yes/no), list of affected apartments in case of duplicate.
Use-case examples: Inventory clean-up; early-warning system for double activations.
Status: Production

Gf-TA HomeID uniqueness

Purpose: Validates that the Home-ID extracted via OCR is unique project-wide (across datasets).
Input: OCR result of the Home-ID + dataset context.
Output: Boolean (duplicate: yes/no), list of conflict cases.
Use-case examples: Carrier-wide inventory-data hygiene; prevention of billing conflicts.
Status: Production

Splice-tray family 4

Splice tray present

Purpose: Detects the presence of a splice tray on an installation image.
Input: JPG/JPEG image.
Output: Boolean (splice tray present: yes/no), confidence score, bounding box.
Use-case examples: Evidence of professional fibre end-assembly; routing to the dependent crimp and colour modules.
Status: Production

Splice tray crimp protection

Purpose: Detects the presence of crimp protection on a detected splice tray.
Input: JPG/JPEG image with a previously detected splice tray.
Output: Boolean, confidence score.
Use-case examples: Conformity evidence of mechanical fibre safeguarding against tensile and kink breakage.
Status: Production

Splice tray fibre colours

Purpose: Detects defined fibre colours (red/green as the primary pair) on both sides of the crimp protection and validates pairwise match.
Input: JPG/JPEG image of the splice tray with crimp protection.
Output: Boolean (matching: correct/incorrect), list of detected colours per side.
Use-case examples: Splice-correctness audit at fibre level; prevention of cross-connect errors.
Status: Production

Splice tray handwritten label

Purpose: Detects the presence of handwritten labelling on the splice tray (no content extraction required).
Input: JPG/JPEG image.
Output: Boolean, confidence score.
Use-case examples: Evidence of documented splice assignment; preparation for downstream handwriting OCR.
Status: Production

ONT family 2

ONT detection

Purpose: Detects the presence of an Optical Network Terminal (ONT) on an installation image.
Input: JPG/JPEG image.
Output: Boolean (ONT detected: yes/no), confidence score, bounding box.
Use-case examples: In-house acceptance; handover of the active end device to the customer.
Status: Production

ONT status

Purpose: Detects the operating state of the ONT based on visible LED indicators or display content (simplified: active/inactive).
Input: JPG/JPEG image of the ONT.
Output: Status class (active/inactive/unclear), confidence score.
Use-case examples: Functional evidence at acceptance; first-light check.
Status: Production

Cable and components family 11

Microduct branch

Purpose: Detects a microduct branch (underground cable split) on an image.
Input: JPG/JPEG image.
Output: Boolean (microduct branch detected: yes/no), confidence score.
Use-case examples: Civil-engineering documentation; inventory GIS enrichment.
Status: Production

Kink protection

Purpose: Detects a kink protection at cable transitions.
Input: JPG/JPEG image.
Output: Boolean, confidence score.
Use-case examples: Mechanical construction-quality check.
Status: Production

Corrugated pipe

Purpose: Detects a corrugated pipe (cable protection variant) as cable protection.
Input: JPG/JPEG image.
Output: Boolean (corrugated pipe detected: yes/no), confidence score.
Use-case examples: Selection between protection variants (PG pipe / corrugated pipe / cable duct) depending on carrier specification.
Status: Production

Rectangular cable duct

Purpose: Detects a rectangular cable duct as a protection variant.
Input: JPG/JPEG image.
Output: Boolean, confidence score.
Use-case examples: In-house installation conformity with carrier specifications.
Status: Production

PG pipe

Purpose: Detects a PG pipe as a cable-protection variant at the cable-protection junction to the Multibox.
Input: JPG/JPEG image.
Output: Boolean, confidence score.
Use-case examples: Standard variant in many NE4 installations.
Status: Production

Cable-protection to Multibox connection

Purpose: Validates, via spatial intersection of the object coordinates, whether at least one detected cable protection is actually connected to the Multibox.
Input: Detected Multibox coordinates + detected cable-protection coordinates.
Output: Boolean (connection present: yes/no).
Use-case examples: Consistency check against "merely deposited" protective conduits without an actual connection.
Status: Production

BEP detection (Building Entry Point)

Purpose: Detects the presence of a BEP (Building Entry Point, grey rectangular housing) on an installation image.
Input: JPG/JPEG image.
Output: Boolean, confidence score, bounding box.
Use-case examples: Home-connection acceptance; primary aggregation key SDI Building.
Status: Production

Black cable ellipse

Purpose: Detects an elliptically routed black cable as a geometric routing pattern.
Input: JPG/JPEG image.
Output: Boolean, confidence score.
Use-case examples: Detection of documented cable reserve; construction-quality evidence.
Status: Production

Black cable rolled

Purpose: Detects a visibly coiled black cable ("black circle") regardless of routing location (inside BEP, in shaft, on wall).
Input: JPG/JPEG image.
Output: Boolean, confidence score.
Use-case examples: Evidence of proper cable reserve at the home connection.
Status: Production

Fibre spliced

Purpose: Detects an executed splice in which the incoming fibre and the customer fibre are visibly connected.
Input: JPG/JPEG image of the splice location/splice tray.
Output: Boolean (splice executed: yes/no), confidence score.
Use-case examples: Customer activation evidence; billing release after splice execution.
Status: Production

Multibox cable labelling

Purpose: Detects the presence of labelling on white NE4 cables in the opened Multibox (labelling present: yes/no; without content OCR).
Input: JPG/JPEG image of the opened Multibox.
Output: Boolean (labelling present: yes/no), confidence score.
Use-case examples: Evidence of traceable cable assignment; preparation for downstream OCR.
Status: Production

Laser-warning family (cross-cutting) 2

Laser warning sticker

Purpose: Detects a classic laser warning sticker (yellow triangle with black laser symbol) on an installation image. Cross-cutting module, applicable to APL, Gf-GV (Multibox), Gf-TA.
Input: JPG/JPEG image.
Output: Boolean (laser warning presence: present / not present), confidence score.
Use-case examples: Mandatory labelling against occupational-safety standards; laser-safety compliance audit.
Status: Production

Laser warning embossed marking

Purpose: Detects an embossed laser warning marking on the hardware surface, as an alternative to the sticker.
Input: JPG/JPEG image of the device.
Output: Boolean, confidence score.
Use-case examples: Capture of manufacturer-dependent marking variants; double-mandatory-labelling audit.
Status: Production

OCR modules (document and device text recognition) 6

Acceptance protocol detection

Purpose: Detects the presence of an acceptance protocol as a document type (classification, without content extraction).
Input: PDF or JPG.
Output: Boolean (acceptance protocol detected: yes/no).
Use-case examples: Document-compliance audit; completeness check of the construction record.
Status: Production

Measurement protocol detection ("dB" trigger)

Purpose: Detects the presence of a measurement protocol on a device display and validates the presence of the "dB" character on the screen.
Input: JPG/JPEG image of a measurement-device display.
Output: Boolean (measurement protocol detected: yes/no), boolean ("dB" present: yes/no).
Use-case examples: Initial acceptance after splicing; construction-execution evidence of the attenuation measurement.
Status: Production

Apartment-number extraction (App. No.)

Purpose: Extracts the apartment number from a detected Gf-TA via OCR (no pattern validation, length limit only).
Input: JPG/JPEG image of the Gf-TA.
Output: String (extracted App. No.) + confidence score.
Use-case examples: Input for the apartment-number uniqueness module.
Status: Production

Home-ID extraction

Purpose: Extracts the Home-ID from a detected Gf-TA via OCR.
Input: JPG/JPEG image of the Gf-TA.
Output: String (extracted Home-ID) + confidence score.
Use-case examples: Input for the HomeID uniqueness module; linkage to the order inventory.
Status: Production

Order-number extraction

Purpose: Extracts the order number from protocol documents or from the file path.
Input: PDF protocol or file-path string.
Output: String (order number) + source (path/content).
Use-case examples: Linkage of image material to order data without file renaming.
Status: Production

Address extraction from protocol

Purpose: Extracts the property address from the content of an acceptance protocol or from the file path.
Input: PDF protocol or file-path string.
Output: Structured address string (street, house number, postcode, city).
Use-case examples: Consistency check against the GPS/EXIF address; GIS enrichment.
Status: Production

OTDR modules (measurement-data analysis) 4

SOR file parsing

Purpose: Parses SOR files as the authoritative source of OTDR measurement data (PDF OTDR protocols are no longer used as a source).
Input: .sor file.
Output: Structured fields: wavelength, range_value, refl_thr, total_loss.
Use-case examples: Machine-based OTDR inventory analysis; avoidance of manual PDF reading.
Status: Production

OTDR attenuation analysis

Purpose: Validates the extracted attenuation values (total_loss in dB) against specified thresholds.
Input: total_loss from SOR parsing.
Output: Boolean (threshold met: yes/no) + value + threshold.
Use-case examples: Acceptance check against carrier threshold values.
Status: Production

OTDR reflection analysis

Purpose: Validates the reflection threshold (refl_thr) against the spec < -55.000 dB.
Input: refl_thr from SOR parsing.
Output: Boolean (refl_thr < -55.000 dB: true/false).
Use-case examples: Connector and splice quality check.
Status: Production

OTDR wavelength plausibility

Purpose: Checks whether the extracted wavelength is in the permitted list (1310 / 1490 / 1550 / 1610 / 1625 nm).
Input: wavelength from SOR parsing.
Output: Boolean (valid wavelength: yes/no).
Use-case examples: Measurement-setup quality control.
Status: Production

Geo modules 3

EXIF GPS presence check

Purpose: Checks whether an image contains EXIF metadata and GPS coordinates without triggering reverse geocoding. Low-cost pre-check.
Input: JPG/JPEG image.
Output: Two boolean columns: EXIF Data Present (Yes/No), GPS Coordinates Present (Yes/No).
Use-case examples: Pre-Validation; audit whether the field crew enabled GPS.
Status: Production

Geocoding - forward and reverse

Purpose: Converts GPS coordinates into structured postal addresses (reverse geocoding) and postal addresses into GPS coordinates (forward geocoding). A single service in both directions - the source of the geo data is encapsulated behind the platform.
Input: Latitude/longitude from EXIF or a free-form/structured postal address.
Output: Structured address fields (postcode, country, city, street, house number) or latitude/longitude; fail flag for an unresolvable request.
Use-case examples: Pre-filling the address field for order creation; geo-consistency audit; enrichment of address lists with coordinates for GIS or planning systems.
Status: Production

Address structuring (postcode/city/street/house number/addition)

Purpose: Normalises the fields returned from geocoding into a canonical form for CSV/Excel output.
Input: Raw address from geocoding.
Output: Fields postcode, city, street, house number, addition; multiple addresses per object are output separated by semicolons.
Use-case examples: Clean, importable Excel data for RIMO/SAP/GIS.
Status: Production

Signature and handwriting modules 3

Signature presence detection

Purpose: Detects the presence of a signature in a protocol document.
Input: PDF or JPG of an acceptance protocol.
Output: Boolean (signature present: yes/no), confidence score, bounding box.
Use-case examples: Completeness audit of acceptance protocols; threshold for payment release.
Status: Production

Signature content OCR

Purpose: OCR attempt on the signature line to extract a readable plain-text name (fallback: empty string).
Input: Bounding-box excerpt from a protocol.
Output: String (plain-text name or empty), confidence score.
Use-case examples: Plausibility check against contractor master data.
Status: Production

Handwriting OCR

Purpose: Reads handwritten notes on splice trays, labels or protocols.
Input: JPG/JPEG image or PDF excerpt.
Output: String, confidence score.
Use-case examples: Digitise splice-assignment notes; full-text index of construction records.
Status: Production

PII anonymisation modules 3

Person anonymisation

Purpose: Detects visible persons in image material and irreversibly redacts them.
Input: JPG/JPEG image.
Output: Anonymised JPG/JPEG, mask, boolean (persons detected: yes/no).
Use-case examples: GDPR-compliant handover to the client; publication release.
Status: Production

Licence-plate anonymisation

Purpose: Detects and irreversibly redacts vehicle licence plates in image material.
Input: JPG/JPEG image.
Output: Anonymised JPG/JPEG, mask, boolean.
Use-case examples: Outdoor shots with parked vehicles in front of building entries.
Status: Production

Doorbell label anonymisation

Purpose: Detects and redacts names on doorbell labels, letterboxes and similar signage.
Input: JPG/JPEG image.
Output: Anonymised JPG/JPEG, mask, boolean.
Use-case examples: Building-entrance shots; protection of third parties.
Status: Production

Integration modules 2

GIS integration

Purpose: Provides a configurable interface to customer GIS systems (inventory documentation, GeoJSON/Shapefile export, Web Map Service).
Input: Module outputs with geo reference (address, lat/lon, asset IDs).
Output: Geo-coded records in the target format of the GIS; optional live sync.
Use-case examples: Enrichment of the carrier inventory database; civil-engineering asset maintenance.
Status: Production

Geo-referencing of inspection results

Purpose: Links module outputs (boolean fields, defect flags) to a precise spatial coordinate so that inspection results can be evaluated on a map.
Input: Module outputs + GPS coordinates.
Output: GeoJSON feature collection with asset properties.
Use-case examples: Hotspot analysis of construction defects; site-management heatmap.
Status: Production

Cross-validation modules 2

Image-vs-protocol consistency

Purpose: Compares facts detected in images (e.g. APL detected) with the fields documented in the associated acceptance protocol and reports deviations.
Input: Image module outputs + OCR outputs from the protocol.
Output: Consistency boolean per inspection dimension, detail columns with detected deviations.
Use-case examples: Detection of "protocol green, image red" discrepancies; fraud detection.
Status: Production

Predictive analytics for defect clustering

Purpose: Statistical analysis of module outputs across a construction lot or carrier region to identify striking defect clusters (by subcontractor, region, period).
Input: Aggregated module outputs across several datasets.
Output: Anomaly score, top-N lists, drill-down tables.
Use-case examples: Subcontractor steering; quality early-warning system.
Status: Production

Pre-classifier module (routing) 1

Pre-classifier

Purpose: Lightweight image classification that runs before every object-detection module and decides which atomic modules are actually invoked for a given image. Filters irrelevant images (private photos, unrelated objects) out of the pipeline. Saves compute time and avoids false positives.
Input: JPG/JPEG image.
Output: Routing decision (list of downstream module IDs to execute); filter boolean (image relevant: yes/no).
Use-case examples: Mass data processing with mixed image content; cost optimisation in cloud processing.
Status: Production

Integration and platform

Fiberproof AI as a functional building block for carriers, service providers and managed service providers.

Do you run your own site diaries, acceptance tools or workflow platforms for FTTH projects? Fiberproof AI is not only usable as a complete solution but also as a modular API platform. Individual detection modules can be integrated directly into your existing tools - multi-tenant, audit-compliant, headless-capable.

REST API with token authentication

Token-based authentication as standard (bearer token instead of HTTP Basic Auth). More secure, rotatable, audit-capable.
Every detection module as an API endpoint: APL detection, OTDR analysis, geo-address structuring, splice-tray inspection. Individually callable.
Role-based views: admin sees the full administration UI, service user sees only the upload endpoint. Clear separation of configuration and use.

One-click upload + instant processing

Headless workflow: upload of a data package triggers immediate processing. No manual UI interaction required.
Pre-configured processing chains per tenant (customer, project, processing config). The end user picks only their data directory and clicks once.
Real-time status feedback: the API immediately returns a process ID; the final status is reported back by e-mail or retrieved via polling endpoint.

Multi-tenant - one platform, many tenants

Per-tenant isolated pre-configurations in the database: each tenant has its own customer/project/module combinations.
Unified code base, instance-specific configuration. Updates reach all tenants consistently, without code forks.
Data isolation at the S3 and database level. No mixing between tenants, no cross-visibility.

Enterprise e-mail layer (verified AWS SES)

Async notifications for every processing run: Pre-Validation completion, processing completion, failure alert.
Verified senders via AWS SES: high deliverability, multi-tenant capable, no manual recipient verification per address.
Recipient logic configurable: notifications go to the triggering user, a central service mailbox, or both, as configured.

Example: a managed service provider integrates the APL detection module into its own site diary. Its end user uploads photos in the site diary; in the background the site diary calls our REST API with a bearer token, receives the structured detection results and writes them into its own database. The end user notices nothing of Fiberproof AI - they simply receive the result in their familiar tool.

All modules in the module marketplace are REST-API capable. Talk to us if you would like to integrate a module into your platform - we will set up the tenant slot, the tokens and the pre-configuration together with you.

Trust and compliance

KRITIS and NIS-2 are not your concern - here is how we decouple them.

The most common concerns about AI platforms come from the KRITIS, NIS-2 and GDPR areas. We answer them structurally - not with promises, but through the architecture of our collaboration.

KRITIS and NIS-2 fall away for you structurally

Our infrastructure is not part of your infrastructure. Fiberproof AI runs as a stand-alone SaaS platform in EU hosting. No mixed operation with your productive systems.
You have no steering role over our operations. You consume the solution as a service, without interfering with our technical operations. As a result, our system is not in scope of your KRITIS or NIS-2 perimeter.
LATUS Consulting AG itself is not subject to NIS-2 (consulting firm outside the named sectors).

GDPR-compliant - with verifiable evidence

EU data residency. Processing and storage exclusively in the EU. A data-processing agreement pursuant to Art. 28 GDPR is a standard component.
Multi-tenant isolation. Your data is technically separated from other customers' data. No mixing, no cross-visibility.
Clearly delimited processing purposes. We process your data exclusively for the purposes defined in the data-processing agreement - no anonymisation for third-party AI training, no re-use.
End-to-end encryption. TLS 1.3 in transit, AES-256 at rest. Multi-factor authentication for all access.

Audit data and deletion - documented on request

Gap-free processing trail per file. On request we deliver audit reports: which file was processed when, by which module, with which result, by which user.
Deletion concept per your specifications. Retention periods are configured per project. Deletion operations are logged and available on request as a signed deletion protocol.
Right to be forgotten. Upon request from the affected person we delete personal data within the statutory deadline and provide proof.
72-hour reporting obligation. In the event of security incidents we notify you as the controller pursuant to Art. 33 GDPR within 72 hours, via defined reporting channels.

Specific requirements from your internal compliance framework (particular reporting obligations, additional audit requirements, ISO 27001 annexes) are incorporated during onboarding.

Frequently asked questions

Answers to the typical questions.

What new customers ask most often in the first conversations - answered concisely.

How quickly can an onboarding start?

A typical onboarding with customising takes 4 to 6 weeks. This covers the kick-off workshop, data analysis, specification of the inspection criteria, model training on your data and provisioning of the test environment. A pilot phase with a representative dataset (5,000 to 10,000 documents) follows.

How good is the detection quality really?

In the documented pilot projects we reach >99% confidence on APL detection. Important: confidence is the detection certainty per object, not the absolute hit rate across all image types. The models are specialised for FTTH components - very high in that context; outside it (e.g. a completely different component type) re-training is required.

Where is the data stored, and is it GDPR-compliant?

Hosting in AWS Frankfurt (EU data residency), end-to-end encryption (TLS 1.3 in transit, AES-256 at rest), VPC isolation, role-based access control (RBAC), multi-factor authentication. A data-processing agreement pursuant to Art. 28 GDPR is a standard component of every engagement. Deletion concept and retention periods are configured per project according to your specifications. An on-premises variant is optionally possible if data classification or internal policy require it.

What about KRITIS and the NIS-2 directive?

Our architecture decouples you structurally from both topics:

Our infrastructure is not part of your infrastructure. Fiberproof AI runs as a stand-alone SaaS platform in EU hosting. There is no mixed operation with your productive systems.
You have no steering role over our operations. You consume the solution as a service, without interfering with our technical operations. As a result, our system is not in scope of your KRITIS or NIS-2 perimeter.
LATUS Consulting AG itself is not subject to NIS-2 (consulting firm, outside the named sectors).
Contractually we govern the collaboration via a data-processing agreement pursuant to Art. 28 GDPR with the customary annexes covering technical/organisational measures, audit rights and reporting channels for security incidents.

Specific requirements from your internal compliance framework (e.g. particular reporting obligations, retention periods, additional audit requirements) are incorporated during onboarding.

How are security incidents handled?

AWS multi-layered security (VPC isolation, IAM RBAC, KMS encryption, GuardDuty monitoring). Data flows are encrypted throughout. On incident detection, the standard AWS incident-response processes apply, in addition to our contractual 72-hour reporting obligation to you as the controller (Art. 33 GDPR). Penetration tests are scheduled per project. Audit trails across every file and every processing step are a standard output of the platform.

Which data formats does the platform process?

Images: JPEG, PNG. Documents: PDF (digital and scanned). Measurement data: SOR files (OTDR), XLSX. Upload via web drag-and-drop, SharePoint, AWS S3 or API. Multi-object detection per image is standard.

How does Fiberproof AI integrate with existing systems?

REST-API-first approach. Each customer receives its own API-key configuration. Output is CSV/Excel or a direct API response. SharePoint integration is available; further connectors (e.g. to GIS systems) are on the roadmap. White-label capability for system integrators is provided.

What sets Fiberproof AI apart from the competition?

Three points: end-to-end solution (image analysis + document review + OTDR validation combined; other vendors typically cover only one part). Forensic mass inspection on legacy inventory (>100,000 documents structured after the fact). FTTH specialisation with pre-configured models instead of a generalist AI.

What data does the AI need for model training?

At least 250 high-quality images per detection pattern. Quality is decisive - poor or empty files are unsuitable. As an industry benchmark: Orange France labelled 80,000 photos in three months of development. We can build on already-trained FTTH models, so each customer does not have to start from zero.

Next step

See Fiberproof AI on your own data.

A live demo shows the solution in 30 minutes using real FTTH data. Optionally followed by a pilot on a construction lot of your choice, with a clear statement on time and quality effects within 4 to 6 weeks.

Open live demo directly Book a demo

LATUS Consulting AG·Built with a trusted software partner in the EU·Hosting in the EU (AWS Frankfurt)·latus-consulting.de