Engineering
in Progress
← Projects

ENPL

Project 001 / In development

An independent
FTTH design agent.

A tool for planning fibre broadband in a village or a few streets. You talk to it in normal language. A local AI model handles the conversation and the judgement calls; the app’s own code does the routine work of reading data, calculating and saving.

In short

  • 1Talk

    Describe the area and what you need. The model asks when something is missing.

  • 2Calculate

    Code reads public registers and does the calculations. The model does not invent numbers.

  • 3Approve

    Changes to the scope, the network and proposed requirements wait for your click.

Working prototypeFull end-to-end test not passed yetNo published test results

What is being designed

Fibre broadband starts at one central point and branches out, street by street, to each building. The agent helps decide where these parts go and how they connect.

Generic FTTH network: one POP feeds three DPs through cables in ducts; each DP feeds two buildings through drop cables.POPDPDPDP
FIG. 1 A generic picture of the terms, not a project output.
POP
The central point where the local network starts.
DP
A distribution point near a group of buildings.
Cable in duct
Runs along the streets inside a protective pipe.
Drop
The short cable from a DP to one building.

Who does what

The model is good at language. Code is good at being exact. The app keeps them apart, and you stay in the loop for the decisions.

YouModelCode

  1. 1
    You ask

    An area, a requirement or a correction, in plain words.

  2. 2
    The model plans

    Works out what is needed and picks a tool.

  3. 3
    The code runs it

    Checks the input, reads the registers, calculates.

  4. 4
    You approve

    Scope, network and proposed requirements wait for your click.

  5. 5
    The code saves

    Stores the result and logs what was actually done.

  6. 6
    The reply is checked

    A second model pass reviews the answer before you see it.

FIG. 2 Steps 2 and 3 (↻) can repeat several times before an answer. The review in step 6 reduces mistakes; it cannot guarantee a correct reply.
CHANGING NOW · OCTOBER 2026

More of the routine work is moving from the model into the app. Preparing terrain data, choosing an address for a drop and sizing a DP now run from app panels that you start yourself, with a preview and a confirm button. The model keeps the conversation, the questions and the recommendations.

The working goal is a simplified project run in about 30 minutes. These changes have not yet passed a full test.

Where the project stands

The app follows the order of a real fibre project. Every stage below exists in the prototype; some are still limited.

  1. Location and scope

    Pick a village, streets or a whole locality from the official register.

    Prototype
  2. Requirements

    Record design assumptions, each with the message it came from.

    Prototype
  3. Terrain data

    Buildings, parcels, roads, heights, aerial photos and utility maps.

    Prototype
  4. Network concept

    Propose where the POP and the DPs go.

    Prototype
  5. Routes and ducts

    Cable routes from POP to DP and a street duct plan.

    Working routes only
  6. Drops to buildings

    From each DP to the building wall.

    Tested on synthetic geometry
  7. Capacity and budget

    Ports, splitters and fibres; optical losses along the way.

    Calculator tested offline
  8. Documentation

    HTML, CSV, GeoJSON and a ZIP from the saved data.

    Working draft
FIG. 3 built as a prototype, built with a clear limitation. Neither means the stage has passed a full conversation test.

The data it reads

All map and address data come from public Polish registers, stored locally with their source and date. Each one answers a narrow question.

Seven registers drawn as stacked layers: KIUT, orthophoto, BDOT10k, EGiB, PRG, NMT and TERYT.KIUTutility mapsOrthophotoaerial photosBDOT10kroadsEGiBbuildings, parcelsPRGaddressesNMTterrain heightsTERYTplaces, streets
FIG. 4 The registers as a stack. A schematic, not a map of real data.
What each source cannot tell us
TERYT
A chosen area is not a confirmed boundary.
PRG
An address is not a building, a flat or a customer.
EGiB
A building outline does not show where the entrance is.
BDOT10k
A road on the map is not permission to dig.
NMT
Heights only, nothing about the ground underneath.
Orthophoto
A background picture, not a technical drawing.
KIUT
A picture of utilities, with no depth and no exact position.

Ground rules

  • Done means done

    A result counts only when a tool has actually run, not when the text says so.

  • A click means yes

    A quote or a later message is not approval of a change.

  • Numbers keep their source

    Optical budget inputs must come from your current message.

  • Old results are flagged

    Change the area or a requirement, and results built on it are marked out of date.

  • Same rules everywhere

    A bug found in one village is fixed for every project, with no special cases.

What this is not, yet

Not a finished network design.

The agent has not passed a full end-to-end test on a fresh project, and long conversations can still go wrong.

The optical budget is a working calculation, not a technical approval, and exports are drafts, not construction documents. Public maps cannot confirm duct capacity, access rights or what is underground, so any result still needs an engineer’s review.

Next step

One small, repeatable test, written up in full: what was expected, what happened, what broke and what changed. Each test entry will name the model, settings, code version and data used.

Read the starting-point note →