Autonomous Engineering
Design & optimize networks end-to-end
Autonomous engineering is Nexma turned toward the design of physical networks — fiber, water, electric, gas, 5G. You describe the outcome you want; Jax designs the network end to end, verifies every design against the rules that govern it, and proves the result is the lowest-cost layout that satisfies them. Work that takes engineering teams weeks lands in minutes, construction-ready, with a defensible record behind every decision.
This is not a separate product. It is the same operating system — Ontology plus DataStore plus Jax plus the engines — surfaced for the people who build infrastructure.
What you can do
- Design any network type. One platform adapts to fiber, water, electric, gas, or 5G by swapping the Ontology. No custom code, no migration, no second tool.
- Generate construction-ready designs. Equipment placement, cable or pipe routing, and resource allocation come out as a complete package — bill of materials, cost estimate, and deployment schedule attached.
- Stay valid by construction. Engineering standards, physical laws, budget ceilings, and regulatory requirements are enforced on every design automatically, not caught in review.
- Optimize, not approximate. The MathEngine evaluates thousands of alternatives and returns the provably lowest-cost design that satisfies every constraint — with the optimality gap reported.
- Explore without risk. Fork the design into a branch, try a different routing strategy or budget, and merge the winner. Nothing touches the live world until you decide.
Core concepts
A network design in Nexma is not a CAD drawing. It is a set of typed entities and relationships in the DataStore, governed by the active Ontology. Every view — globe, table, graph, diagram — is a read off that one source of truth, so a routing change propagates to every surface at once.
- The Ontology carries the rules. Splice ratios, pressure limits, voltage drop, clearance requirements — domain constraints live in the world model, not in tool code. Change the Ontology and the same engine designs a different network.
- Jax composes the primitives. Design is not a special API. Jax reads state, runs deterministic geo-math, calls
Solvefor optimization, and writes the result back — the same eight primitives every capability uses. - The MathEngine proves it. A layout that satisfies a deadline is not the same as one that satisfies an objective. Optimization returns a plan and a proof of how close it is to optimal.
A design is valid by construction when the solver's constraints come straight from the Ontology. You are not reviewing for compliance after the fact — non-compliant designs were never in the search space.
How it works
You state the goal in plain language. Jax formulates the problem against the world model, the MathEngine solves it, and the result is written back as a versioned design.
1Goal: "Design the lowest-cost fiber network that serves every household in this polygon."
2 1. Read households + existing infrastructure from the DataStore
3 2. Read constraints from the Ontology → splitter ratios, optical budget, budget cap
4 3. Solve formulate as MIP → site cabinets, route cable, allocate splitters
5 4. Verify re-check every constraint; self-correct any violation, re-solve
6 5. Write designs/network-v3.json + bill of materials + cost estimateThe plan is declarative and versioned alongside the world model it acts on. If a result violates a domain constraint — a closure over its optical budget, a pipe past its pressure limit — Jax detects it, reformulates, and re-runs before returning anything.
What the design package contains
| Output | What it is |
|---|---|
| Network layout | Equipment placement, cable or pipe routing, splitter or transformer allocation, all geolocated |
| Bill of materials | Itemized quantities for every component, ready for procurement |
| Cost estimate | Full cost breakdown tied to the chosen layout, comparable across design alternatives |
| Validation report | Every constraint checked, with binding constraints and the optimality gap named |
| Deployment schedule | Sequenced work, ready to hand to operations and the field |
Example
A broadband operator needs to plan three adjacent service areas with a shared backbone.
- Load the FTTH Ontology and import building footprints and the existing duct network.
- Ask Jax: "Design all three areas together, optimizing the shared backbone, under a $1.2M cap."
- Jax sites cabinets, routes feeder and distribution cable, allocates splitter ratios per area, and shares the backbone across all three to cut total cost.
- The result comes back as three branchable designs with a combined bill of materials, a cost breakdown, splice diagrams with TIA-598 color coding, and a validation report confirming optical budget on every path.
- The operator forks one area into a branch to test a denser splitter strategy, compares cost, and merges the cheaper option.
Swap the Ontology to water or electric and the same flow designs a distribution main or a feeder circuit — the steps are generic, the meaning comes from the world model.
Where to go next
- Nexma MathEngine — the optimization that makes designs provably optimal.
- Ontology — where the constraints every design respects are defined.
- Branches — explore design alternatives without touching the live world.
- Operations Management — take an approved design to the field and close the loop.
- FTTH skill — the first engineering domain, end to end.