Route Generator

Part 1: The Prompt

The original request, 2026-09-16:

I want to make another run at building the Route Generator.  I'd like to take a fresh look at it without being influenced by past sessions about it.

The idea is this...  we need a way to explore route options for new-build underground telecom routes/construction between a given Point A and Point Z. We haven't really drilled down on how we get this done manually--what our process is...  it's a bit of a free flow where we have a number of things in mind when we look at different paths...  because we haven't done the work to figure out how we're thinking when we do this, it's difficult to give you much instruction on what the process should be...  so I'll give you the factors that we consider and I'll give you my best guess at what the generator should do...  but I'm looking for you to help me figure out how the solution should work (and how to build it).

Cost and physical diversity from "other carriers" is the customer's biggest concern.  Cost is driven by: 1) work types (bore vs. trench [and ideally vs. plow vs. spiderplow]) and soil types (sand/dirt/clay vs. easy rock vs. hard rock vs. nearly-impossible rock), which we can think about in terms of work type x soil type; 2) major crossings (major bores) of a certain length become vastly more expensive than the day-in, day-out bores that most directional drills can perform.  A 400 linear foot bore under a parking lot is not a big deal.  A 400 linear foot bore under a deep creek requires a more powerful, more expensive drill with more drill stem.  A 700 linear foot bore under a river is is more expensive than that.  A 3000 linear foot bore under a major river is many multiples more expensive--maybe 50x or more than a typical dirt bore.  Etc.  Casing requirements cost money in materials and labor (larger diameter HDPE, which must be fused or steel casings which must be welded), and they add weight and can increase bore reamer diameter, which increases the size and expense of the directional drill needed; 3) length of route increases cost...  so we have to balance an elongated route in dirt vs. a shorter route that requires a wider crossing or more difficult soils (latency is also a concern of the customer and is impacted by route length, but I think it's mostly covered by solving for cost for almost all scenarios); and then 4) metro areas are more expensive than rural and suburban areas, in varying degrees...  a nearly zero-population desert area under only county jurisdiction on one end of the spectrum (think Pecos, Texas) vs. a dense urban location with complex jurisdictions, lots of pavement remove/replace, lots of rules/constraints, significant traffic control requirements, dense existing utilities, etc. on the more difficult end of the spectrum (Atlantic City or Manhattan for example)...  with lots of variation in between...  but in general, when we can avoid metro areas, we should, and when we can't avoid a metro area, then we should avoid the denser and more-paved or higher-sensitivity areas of that metro area, with the most extreme being a central business district, or similar area of a city.

So those are the factors impacting cost which we need to balance against one another, maybe among one another in balance, as we determine an ideal route.

Then there's the issue of physical diversity.  The carriers all want to be far, far away from other carriers to ensure that if one of their connections gets cut, this new route they're purchasing will serve as a backup/redundant connection.  In theory they would only care about diversity from the routes that they currently utilize/depend on, but typically they want to keep diversity from any carrier that they might depend on in the future.  So maybe they don't care that much about running parallel to an FTTH network, but they want to stay diverse from major carriers such as Lumen and Zayo and FiberLight, etc.

Routes all have to follow public roads.  These fall under various jurisdictions.  Certain jurisdictions are easier than others--toll roads might be the hardest depending on the entity, then interstate highways are typically more difficult than state highways/on-system DOT roads, and then city roads and county roads can be unpredictable--though usually county roads are as-easy as state highways and then city roads are often more difficult than on-system DOT roads.

Here is how I think this might work best...  We start with the soils.  This is easy for me to do by looking at the raster graphic we have--I can look at the colors and could generally draw a curvy line that follows the sand/dirt/clay regions and tries to go in between the rocky areas, minimizing the amount of rock as much as possible and favoring easy rock over dense rock wherever possible and entirely avoiding the densest rock.  Again, that's easy for me to do by looking at the map and kind of feeling my way through it, but it's maybe difficult to program for.  Once that's done, then I could try to match up those curvy lines to roads.  In my mind, my map would then highlight every possible public road route that matched my rock-avoidance strategy.

Then if there was just too much rock to route around--meaning the extended length of the route made it so that it would be cheaper to just go through rockier areas, then I could make those tradeoffs.  At that point, I would screen against existing major carriers that I think the customer would be worried about.  I might even be willing to go through a little more rock to have a more diverse path, depending on how much diversity I could get in consideration of the greater expense.  That's a difficult thing to apply a metric to, perhaps.  It might depend on how strongly the customer emphasized an interest in a diverse route.  It might depend on my sense of their budget.  Then even looking at the diversity of particular options/segments/sections, I can't immediately tell you whether it would it be a simple calculation of diversity vs. rock and cost or whether there might be more nuanced factors that I can't immediately articulate or identify--I suppose for that it would be just a simple calculation and we would be able to adjust the threshold of that cost vs. diversity weight based on the customer's level of emphasis on diversity...  Again, we kind of feel our way through it--we'd try to avoid metro areas along the way wherever possible--I don't know where that sits in the hierarchy...  towns are easier than cities, smaller cities vary but are usually easier than bigger cities, unless it's a particularly easy city...  often the diversity preference helps us avoid the densest metro areas.

At that point, I would go and look at major crossings...  What's the quantity of long or difficult bores?  Are there any in there that would be particularly difficult--super long or maybe a corps of engineers crossing vs. one that's not under their jurisdiction...  would another route take me through a little more rock but allow me to cross at a place where the river is much narrower.

Regarding diversity, I'll add this as well...  we're not going to be able to be 100% physically diverse.  That's feels like a big area of what I call the "feel" aspect--I cannot give you a very clear measure of what my length vs. rock vs. cost vs. diversity metric/ratio is.  It also maybe shifts...  like if I can get from 85% diversity to 95% diversity with higher expense, maybe I'm okay with it because I think that very high figure might sell well to this customer.  But then if it's the difference between 75% diversity and 85% diversity, but there's a big cost or much longer route, maybe I don't care as much.  In another situation, I might be willing to pay a lot to get from 75% to 85%, but I wouldn't care nearly as much about getting from 85% to 95%...  Similarly, I might say that I would never accept a route with less than 50% diversity or maybe 60% diversity...  but it depends how dense everything is what other options there are and what the cost spread might be.  It might ever vary based on looking at something where I could follow a given route and overall have higher diversity, but portions of that route are particularly dense with many major carriers--in that case I might pick a route with lower footage percentage diversity, but where it only conflicted with a single carrier.  But then I can't say I would always choose that because there might be a bottleneck like a river crossing at a bridge where that's just the only place to cross and so everyone is there...  It's difficult to set hard and fast rules.

Length vs. cost is maybe an issue here as well...  like if a route were technically cheaper, but it was just WAY longer, then maybe that's something where we'd go ahead and just pay the extra money...  I'm not sure...

One way we could approach this is to consider it an "exploration" tool rather than something that would give us a single best answer...  Maybe the goal here should not be to solve the route generation issue, but just to speed up the way the human can make their determination?

It's a hard call.  Ultimately I'd like to have something where a customer could just enter a Point A and Point Z and it gives them the 10 cheapest route options.  Maybe that could be accomplished via sliders that weigh various factors?  We've taken a number of stabs at this, and we haven't gotten anything usable yet.  For that reason, I'm thinking maybe it's more like an exploration tool?  I would also like it not to use some incredible amount of tokens or processing power--if it must, it must, but speed of route option generation and expense are real considerations here.  I don't want to make it overly complex.  I'd like to get something that we can use--it doesn't need to factor in space weather and pavement replacement cost...  it just needs to accomplish our goal in a reasonable way that works similarly to how we work.

Please generate a prompt for this and then answer that prompt.

The follow-up, 2026-09-21, answering Design Round 01:

Regarding the design document...  I want it hosted online.  Put it at routegen.fiberbid.ai.  (ESET is gone by the way.)

I want roadway jurisdictions solved nationwide, but I think that's already done somewhere else--possibly.  For now we can use Open Street Map and we can figure out the solution for the rest later.  But you'll want to do a comprehensive search of all sessions, because we may have already addressed this in a big way.

Nearly impossible rock needs to be permitted--Class 9...  just needs to be marked rated at like 100x cost.  I've attached what I want you to use for the costs.  It's meant to be structured where everything is a multiple of the bore-dirt cost.  We can stick with these as the defaults, but I should be able to override them when necessary--the easy level being that I just change the dirt bore rate and everything else auto-calculates off of that, or the more involved level being that I can override individual rates if desired.  You likely won't be able to judge plow vs trench, so it's going to be bore vs. not bore and for not bore we'll use the trench multiples and rates.  We'll just keep the spiderplow and vibratory plow stuff in there as placeholders for possible future functionality.

DO NOT try to solve to our routes--I'm not necessarily entirely happy with any of them.  We can compare just to see, but they are not the benchmark.  Yours will be better.

Soils raster is in the inputs folder.  Latest GeoTel data is in the inputs folder.

2. Agreed.
3. You definitely have to keep interstates.  You also also keep toll roads--if there are other carriers in that ROW, then it's an option that shouldn't be completely excluded--sometimes that's the only way.  Any section of a public road that can be built in should be included as a possibility.  At some point we probably have to figure out "inaccessible" areas where they won't let you build, but that seems to be quite difficult--the official files we've found for Texas do not appear to show what we were looking for...
4. I'm good with these for now.  I'd like to have those multipliers available as assumption variables where I can modify the defaults and/or specify for a specific route exploration session/project.
5. Soils rasters and carrier routes are in the folder.  Bid calc is saved there as well.  Three example bids/routes.  Again, though, don't solve to the example bids because I'm not necessarily happy with these.
6. Nothing I can think of.

Part 2: The Answer

The document above.  Judgment calls settled while producing it:

• Class 9 defaults to the calculator's 37.5 times, not the "about 100 times" said in passing, because Jeff named the calculator as the cost source.  One assumption line changes it.
• The crossing tiers use the calculator's three per-foot rates.  The length and type breakpoints that assign a tier are Claude's, kept as assumption variables.
• Not-bore is allowed outside city limits, under 10 percent pavement, soil class 7 or lower.  Trench has no rate for classes 8 and 9 in the calculator.
• Metro and permitting multipliers are placeholders Claude chose, flagged as such, to be calibrated in step 4.
• Jurisdiction comes from the FiberBid RoadAuthority layer found in a search of all sessions on 2026-09-21, not from OpenStreetMap road class.  OpenStreetMap stays the routable graph.
• The 46 GB of inputs stay in the project folder where Jeff put them, against the file standard, and the state file records that.
• Earlier Route Generator projects were not read for their design.  The session search touched them only to find jurisdiction-related data pointers.
• This document is hosted at routegen.fiberbid.ai on Vercel, with the 2026-09-16 roads-only explorer beside it as a demonstration.