OpenSourceRail develops affordable urban rail and the open tools needed to plan, design, procure, manufacture, construct, operate, maintain and renew it. The aim is to retain design authority, software, fabrication, integration and repair capability in-country, with competitive sourcing of specialist components.
v0.6 is the station-powered freewheeling reference railway: lightweight comfort cars run on passive steel-wheel bogies and conventional rails on precast concrete structures. Wayside linear-induction motors launch and receive the train through passive onboard reaction elements. Normal-service traction motors, traction batteries and levitation magnets are absent from the train; passenger services, essential power, protection and independent brakes remain.
The wider project encompasses city planning, CAD/BIM, manufacturing, business execution, equipment supervision and open controls. The current v0.6 front end exposes planning proposals, candidate engineering and delivery records; business and supervision functions require separate configuration, and complete city delivery remains open. The railway is a research and prototype design, without manufacturing or operating release.
Start here: how the whole system works · illustrated reader · project overview · current platform capabilities · current engineering · sourcing and cost evidence · city geography · roadmap.
Architectural concept, not approved geometry: six 17 m cars, passive steel-wheel bogies, flush roof solar panels, conventional rails on repeatable precast beams and a compact station. Inspect the source-bound counted vehicle geometry; that geometry and its source-account balances do not establish a complete installed train or manufacturing release.
- Build useful capability locally. Develop concrete precasting, structural fabrication, GFRP panels, interiors, winding, wiring, assembly, inspection and maintenance alongside the railway. Qualify local suppliers rather than assuming every component can already be made locally.
- Keep ownership of the design and information. Open software, drawings, interfaces, component identities and maintenance records let an owner change suppliers and repair equipment without depending on one closed turnkey provider.
- Simplify the complete installed system. Compare vehicle mass, bogies, station power, beams, piers, foundations, equipment, factory tooling and erection together. A cheaper train that requires more expensive stations is not automatically a cheaper railway.
- Serve constrained urban corridors. Mostly elevated, prefabricated construction and compact stations aim to reduce surface occupation and site disruption. Land, utilities, buildings, ground conditions, drainage, access and evacuation still govern each route.
- Offer comfortable, frequent travel. The reference prioritises seated accommodation, wheelchair spaces and a two-minute service target. Capacity, dwell, safe separation, transfers and whole-system cost must be evaluated together.
Local content means origin-traced domestic value added, not the address of a distributor. Imported cells, semiconductors, bearings, sensors, materials and machinery retain their actual origin. No local-content percentage or cost saving is established until the installed BOM, processes and supplier evidence support it.
| Product | Purpose | Present boundary |
|---|---|---|
| Design and delivery tools | City inputs, design alternatives, engineering evidence, quantities, procurement, manufacturing and project records | Current v0.6 Workbench, planning editor, candidate exports and integration components; complete city-specific delivery remains open |
| Reference railway and manufacturing system | Lightweight vehicles, stations, civil works, tooling, assembly and repair methods | v0.6 physical candidates and numerical studies; equipment, drawings, suppliers and physical qualification are incomplete |
| Open GoA4 control software | ATP, interlocking, station-led dispatch, train supervision and fault response | Rust research software, simulation and formal/method checks; no live railway or safety approval |
The first adoption path describes the current planning and engineering interfaces, candidate delivery drafts and separately configured business and supervision integrations. Owners can use them to organise research and review before a train is qualified; they do not provide a live railway operating interface.
The intended end-to-end loop is: define the transport need → generate competing designs → calculate and test them → plan their manufacture and construction → estimate complete costs → revise and compare → approve, build and operate. Every revision should flow through the same vehicle, station, civil, factory, service and financial models. A change to a panel, bogie, beam, winding or service assumption must automatically update all affected quantities, analyses, tasks and costs.
| Stage | What the platform should do | Output and next decision |
|---|---|---|
| 1. Define the remit | Record city geography, passengers, station locations, comfort, speed, climate, accessibility, safety, local manufacturing capability and target cost | One versioned requirements and site scenario; distinguish mandatory requirements from preferences |
| 2. Generate alternatives | Explore vehicle materials/shapes, structures, bogies, propulsion, stations, beams, foundations and production methods—not just small parameter changes | Several fully identified competing physical candidates |
| 3. Detail and check | Produce CAD/BIM, part-by-part installed BOM, weight/CG/inertia, joints, service routes and manufacturing interfaces; run structural, motor, braking, thermal and fault models | Explicit pass, fail or missing-evidence records for every candidate |
| 4. Repair and iterate | On failure, revise geometry, material, component, assembly method or entire architecture; rerun dependent calculations without relaxing safety requirements | New candidate generations with ancestry and Pareto comparisons |
| 5. Calculate build costs | Derive gross material quantities, labour/process hours, machine time, tooling and QA from each design; use dated rates or declared engineering assumptions even where no quote exists | Low/base/high factory, delivered, installed and whole-life planning estimates, with confidence and exclusions |
| 6. Plan production and construction | Generate EBOM/MBOM, assembly order, precast and vehicle factory throughput, workstations, crews, inspections, haulage, cranes/launchers and site sequence | Capacity, workforce, construction duration and cashflow scenarios |
| 7. Review and execute | Compare equal-service candidates and independently check the preferred design; prepare procurement, production, project, QA and training records in ERPNext/Frappe HR | Reviewed handoffs; purchasing, fabrication, installation and commissioning require human approval |
| 8. Operate and improve | Integrate approved equipment, GoA4 protection, FUXA monitoring, maintenance, serial records and actual measured hours/consumption | Real performance and cost evidence fed back into new design revisions |
This is the target workflow, not a claim that every stage is already commissioned. The current generator, engineering Workbench, component registry, numerical models and preliminary manufacturing/cost outputs cover much of stages 2–5. City-specific production schedules, site-validated quantities, physical proof, approved business transactions and operating integration remain incomplete. See the step-by-step cost and delivery implementation plan.
A failed design is not the end of the process. The coordinator should diagnose why it failed, propose a larger change where necessary, and rerun that candidate through weight, simulation, factory work, construction and whole-life economics. Missing prices can trigger calculated estimate ranges; missing safety-critical physical evidence must still block physical approval.
Candidate completion is reported in three separate levels: simulation complete for a named scope with measured or explicitly assumed inputs; engineering validated with credible physical evidence and independent review; and approved for manufacture or operation under the applicable safety, accessibility and release requirements. A completed provisional cost scenario does not imply an integrated journey simulation, engineering validation or release. The current counts and evidence rules are in the coordinated railway report.
The separate conditional P1 journey study runs low/base/high assumed force maps through the reduced journey model for the 28 coordinated campaign variants and the exact selected v0.6 vehicle. The selected vehicle keeps its physical identity while its P1 route remains a separate evaluation. These cases are assumption-only; they do not change the coordinated report's count of completed physical journeys.
The current same-candidate 0.053125 m refinement generated 290,660 C3D8I cells. CalculiX failed during factorization under the declared 10 GiB address-space limit (return code 255; peak RSS 9,838,628 KiB), so it produced no numerical result. The exact request, generated deck, solver logs, producer source snapshots and reuse record are retained; the failure was reclassified from that immutable attempt without rerunning the solver. A future refinement needs a supported solver/resource envelope. See the coordinated engineering report.
The selected vehicle mass reserve sensitivity turns the existing positive mass-account residuals into provisional low/base/high tare scenarios by replacing each residual once. It does not label the vehicle's installed mass complete.
development-baseline.toml selects one reference vehicle, body, running gear and propulsion configuration. Research alternatives receive separate identities and do not silently replace it.
| Design choice | Reference basis |
|---|---|
| Formation | Six 17 m cars; approximately 104.5 m including gaps |
| Comfort | 44 fixed seats + two wheelchair places/car; 276/train; no planned standing |
| Layout | Four abreast where structure permits, wall benches at doors; two passenger doors on one side |
| Body | Aluminium/GFRP architecture, sandwich floor/roof, lightweight benches and glazing |
| Running gear | Twelve unpowered two-axle bogies: 24 axles, 48 wheels |
| Propulsion | Station double-sided LIM reference; passive aluminium secondary on each car |
| Ordinary guideway | Conventional rails and fastenings on precast concrete; box, twin-beam and U-beam comparisons |
| Services | Flush solar roof and a separately sized auxiliary battery; HVAC, doors, ATP and emergency loads remain |
| Automation | Station-led GoA4 architecture, continuous onboard ATP and independent mechanical brakes |
| Network | Passenger transfers between fixed lines; no mainline switches, with depot exceptions explicit |
| Service targets | 72 km/h, 0.4 m/s² acceleration, 0.6 m/s² service deceleration, 35 s dwell, 120 s headway |
| Capacity arithmetic | 8,280 passengers/hour/direction at 30 departures/hour; protected headway remains unqualified |
The normal passenger cap is a comfort and load-management choice; it does not remove crowd, evacuation or accidental-load checks. Structural checks retain a 160-person/car crowd-load control case. One-sided doors require compatible platforms, accessible boarding and emergency exits. Any change to propulsion, formation or passenger loading is a separate candidate whose mass, energy, vehicle, civil, factory and service effects must be evaluated together.
Loss of station propulsion leaves the vehicle supported on its wheels. Independent braking must remain available, and a train stopped outside a powered zone needs a protected recovery/towing and evacuation arrangement. Walkway removal or a proposed escape device is not treated as approved.
A separate practical launch comparison applies the same 1.5 km and 2 km analytical route matrix to 12 station-LIM, wheel, roller, cable and gravity concepts. It exposes required effort, peak mechanical power, route bounds and open force-map, thermal, stopping, recovery, grid and headway evidence; it does not produce a physical journey. The selected wheel/LIM reference remains unchanged.
The selected v0.6 reference uses passive bogies with station LIM propulsion and no onboard traction motors or traction store. Its reference dossier retains a 900 m winding allocation per station and direction. The separate station-accelerator research investigates five aligned 20 m banks (100 m active length) as a distinct alternative; that geometry is not the selected reference. In either configuration, available thrust, safe stopping, recovery and installed price remain open.
The 900 m reference and 100 m research geometry require separate force maps, electrical/thermal duty, plant and civil quantities, procurement BOMs and installed costs. Their lengths and results are not combined or transferred between candidates. The five-bank candidate now has unsent, candidate-bound bank RFQ scope drafts with a common 1.5/2 km duty matrix, sourced local fabrication leads and explicit converter, cooling, protection and installation holds; no supplier response or physical force map has been obtained.
The current candidate export manifest and coupled delivery index expose candidate-bound CAD/IFC, engineering BOM, manufacturing, procurement, assembly and controls records. ./osr twin export inspects these outputs. They do not establish complete installed equipment, a physically supported journey, approved production instructions or operating acceptance. The cost and delivery model calculates provisional factory, delivery, installation and lifecycle ranges when supplier quotes are unavailable; assumptions, uncertainty and evidence status remain attached.
| Passenger-focused lightweight car | Locally assembled, modular construction concept |
|---|---|
 |
 |
| Seated comfort, level circulation, wheelchair provision and passenger services remain even without onboard traction motors. | Structural shells, window/door modules, service conduits, roof solar, equipment and unpowered bogies are conceived for repeatable offsite assembly and inspection. |
| Rapidly placed, minimal precast guideway | Station-powered LIM interface |
 |
 |
| Two conventional rails per direction on slender repeatable precast beams, with site access, containment, drainage and erection requirements to be engineered. | Power equipment is beside the track in the launch/receiving approaches; the vehicle carries a passive aluminium secondary and independent friction braking. |
All five rendered images are concept illustrations; visual attachments, finishes and site arrangements are not qualified CAD or construction details. The drive diagram is an explanatory schematic, not a simulated trajectory. The present reference allocates 900 m of shared winding per station and direction, covering the calculated launch and receiving zones together, rather than a short motor confined to the passenger platform. This allowance does not establish the powered or coasting distances between stations. A separate five-bank research layout uses five 20 m drive banks (100 m active length); it is not a shortened BOM or a performance variant of the 900 m reference. It requires separate force, electrical/thermal, civil, equipment-quantity and cost calculations, and results do not transfer between the configurations. Actual moving-entry LIM thrust, full vehicle mass, protected stopping and civil structures remain unverified. The selected candidate now has a Class C whole-system estimate for a synthetic 6 km corridor; supplier/site-validated cost and equal-service economic superiority remain open. See the current moving-LIM evidence and candidate-to-journey closure work.
The illustration brief records the supplied prompts, source images and display-copy recipe.
The v0.6 workflow links candidate revisions to engineering and delivery records. The Workbench exposes current candidate exports and links to the separately configured business and supervision components:
| Capability | Where to inspect it | What remains necessary |
|---|---|---|
| City geography and planning | 266-city geographic register, source-verified planning workspace | Current map context and route/service proposals; survey, demand, grades, route fit and service evaluation remain open |
| Engineering Workbench | ./osr workbench, current UI, coordinated design experiment |
Available physical models, complete equipment and independently confirmed designs |
| CAD, BIM and quantities | Current CAD/IFC and delivery records, candidate body-stock IFC packages | Complete installed geometry, tolerances, full civil federation and surveyed interfaces |
| ERPNext and Frappe HR | Business deployment and integration app | Configured legal entities, roles, calendars, masters, reviewed imports and production procedures |
| Equipment supervision | FUXA/gateway deployment, integration source | Authenticated device bindings, current equipment models and deployment-specific commissioning |
| Manufacturing and procurement | Reference manufacturing/procurement exports, coupled EBOM/MBOM and assembly records | Supplier configurations, prices, tooling, labour, QA, inspection and release |
| Maintenance and evidence | ERPNext lifecycle app, FUXA and gateway integration | Real serials, measurements, approved procedures and independent handback |
| Train protection and supervision | Rust crates, v0.6 control adapter | Physical braking, localisation, timing, hardware and operating assurance |
The ERPNext app provides draft project, procurement, stock, workforce, manufacturing, quality and maintenance workflows when deployed and configured. FUXA and the gateway provide observation, trends, alarms and review-linked lifecycle integration when connected to authenticated equipment. Business case closure, an alarm reset or a completed repair cannot approve manufactured hardware or grant movement authority.
The current v0.6 candidate exports carry candidate-bound CAD/IFC, engineering BOM, manufacturing, procurement, assembly, civil and controls records. The manufacturing and assembly exports also carry low/base/high process-hour work packages linked to selected cost-line identities, quantities and source/occurrence records. Hours remain provisional; they are not timed work instructions, crew assignments or qualified production capacity, and broad assembly operations remain unallocated where no direct mapping exists. Unlocated equipment, compatible supplier prices, complete installed quantities and physical acceptance remain open. ERPNext/Frappe HR and FUXA/gateway handoffs use their own configured permissions; generated business records remain disabled drafts until reviewed.
transport requirements + city/site inputs
↓
candidate geometry + materials + installed equipment
↓
physics / interfaces / quantities / manufacturing evidence
↓
EBOM + MBOM → suppliers + assembly + inspection tasks
↓
project schedule + resource plan + local/import cash requirements
↓
reviewed business records + serial installation + maintenance history
The current v0.6 coordinator binds the selected candidate through engineering, inventory and delivery drafts. Planning handoffs carry route, stop, service and OD proposals only; they are verified with ./osr plan verify. Candidate-specific construction schedules, complete priced cashflows, approved production data and measured operating records remain open until their inputs are available.
From a verified planning handoff, ./osr twin factory-draft compile build/my-plan --output build/factory-plan creates a provisional six-car factory work package; ./osr twin factory-draft verify build/my-plan build/factory-plan checks its source and candidate identities. The draft carries modelled production hours and low/base/high cost estimates under the declared two 8-hour production shifts. It does not release procurement or manufacture, and it does not complete site civil schedules or operating acceptance.
OpenSourceRail calculates provisional prices for panels, chassis members, bogie parts, electrical equipment, LIM banks, precast beams and installation activities even when no finished product or supplier quotation exists. The candidate-bound cost model connects material and supplier evidence to manufacturing, civil, delivery, operations and lifecycle estimates. Each scope records its inputs, assumptions, uncertainty and exclusions.
A simple first estimate is (gross material quantity × material rate + direct labour hours × hourly wage) × 1.20. The 20% is a declared illustrative allowance for a quick fabrication screen, not an approved market margin. A fuller estimate adds separately counted machine hours, energy, mould/tooling amortisation, consumables, inspection, scrap and rework, with any overhead applied once to a stated cost base. Delivery, cranes/erection, foundations, wiring/connection and testing are then added to obtain installed cost; fleet, staffing, electricity, maintenance, replacements and downtime form the whole-life model.
For example, a GFRP panel should be priced from ply areas, glass/resin/core quantities, inserts and fasteners, mould preparation, layup/infusion, curing, trimming, assembly and inspection hours. A 20 m precast span should include concrete, reinforcement, prestress, mould cycles, curing, crew, transport, lifting, bearings, rail equipment, piers and foundations. Changing the part shape, material, section or method should regenerate both its cost and its engineering checks.
Cost records need explicit low/base/high scenarios, quantities, source dates, currency, locality, labour and yield assumptions, and one of three statuses: model-cost complete (internally estimated), procurement ready (reviewed real purchasing basis), or physically accepted (separate engineering and safety evidence). A Class C estimate is sufficient for provisional economic ranking, not for a supplier commitment, a certified design or passenger operation. Missing parts and costs are never silently valued at zero. See the detailed implementation and regression plan.
The manufacturing objective is a repeatable system a local builder can fabricate, assemble, inspect and repair. The design search compares frames, sandwich panels, honeycombs, material arrangements, joints, inserts, floors, roofs and integrated service supports. Joining, fire/thermal behaviour, tooling, access and replacement matter alongside stock mass.
Breadth-first exploration retains different physical families before detailed refinement. The body portfolio compares 54 stock compositions; the 20 m civil competition generates 18 box, ribbed, varying-depth, folded and hybrid geometries with provisional manufacturing and delivery costs. Family-preserving archives and bounded next-evaluator requests keep inexpensive quantity screens separate from structural qualification. Optional pymoo/pyribs adapters check the evaluated archives; arbitrary topology and organic-surface discovery remain development work.
Civil alternatives must include rails and fastenings, beam stiffness and torsion, bearings, piers, foundations, containment, drainage, emergency access, transport and erection. Common precast parts and offsite inspection should reduce site operations; minimum concrete volume alone does not identify the least-cost structure.
The economic comparison covers rolling stock + guideway + stations and power + factories and construction + energy + maintenance and renewals + service availability. Passenger capacity, headway, fleet size and travel time belong in the same comparison. Local/foreign-currency procurement and financing sensitivity matter, but financing terms are separate from physical resource cost.
The selected v0.6 vehicle now has a separate Class C estimate for factory production, assembly and a 50 km reference delivery. A candidate-bound synthetic system estimate covers all 14 declared cost scopes for a 6 km, three-station corridor. Its installed CAPEX is IQD 59.16 / 286.49 / 1,721.96 billion and its 30-year whole-life NPV is IQD 123.14 / 672.06 / 5,806.45 billion, low/base/high. These wide coupled scenarios are not confidence intervals, a city budget, supplier prices or proof of economic superiority. City-specific costs, site quantities, physical journey evidence and independent acceptance remain open. The current Workbench shows the candidate-bound vehicle and system estimates.
The current dossier records the selected candidate and its evidence. The coordinated railway campaign passes one candidate identity through geometry, mass, analysis, delivery and costing. A research scenario may use explicit assumptions to complete a calculation; physical validation and release remain separate gates.
| Workstream | Current capability | Open evidence |
|---|---|---|
| Candidate design | Composable body and system alternatives with ancestry and candidate-bound downstream evaluations | Broader validated evaluators and independently confirmed Pareto selections |
| Installed inventory | Component identities, geometry-linked stock and explicit mass reserves | Located equipment, complete installed mass, centre of gravity, inertia and interfaces |
| Propulsion and journey | Candidate-specific LIM, braking, electrical and conditional journey calculations | Available motor force and thermal maps, validated stopping and a physically supported protected journey |
| Production and civil works | Candidate CAD/IFC, BOM, process, assembly, procurement and provisional construction quantities | Complete installation scope, site data, qualified processes and supplier evidence |
| Cost and service | Research-bundle Class C scenarios plus selected-vehicle and synthetic-corridor Class C estimates | City-specific site quantities, compatible prices, operating performance and independently reviewed equal-service comparison |
| Business and supervision | Candidate-linked draft ERPNext/Frappe HR and FUXA/gateway handoffs | Configured organisations, reviewed records, authenticated devices and commissioned procedures |
| Verification | Source-bound publications, independent numerical checks and software workflows | Prototype correlation and physical engineering, manufacturing and operating acceptance |
Current cost scenarios use two 8-hour production shifts and two 8-hour civil shifts. Operating costs cover two shifts for 16/18-hour service and a three-shift 24-hour case. These staffing and shift premiums are planning assumptions, not an approved local roster.
The selected candidate now has internally calculated factory-to-lifecycle cost coverage for one declared synthetic corridor, with visible assumptions and separate physical-validation holds. The next economic work is to replace generic account allowances with supported account-specific estimates and to replace synthetic corridor and site proxies with candidate-specific survey, service and quantity inputs. The software labels calculated, benchmarked and supplier-confirmed values separately.
All 266 city geographies remain available as planning inputs. The workspace uses indexed routes, station and transfer locations, plus source-verified road, water, building, land-use and place context where supplied. It supports local route, stop, service and origin–destination proposals. ./osr plan compile edits.json --output build/my-plan creates an immutable handoff bound to the selected v0.6 candidate; ./osr plan verify build/my-plan checks its candidate, source and payload identities. The handoff contains proposals only. It excludes vehicle, propulsion, fleet, civil quantity, cost, performance and cashflow results; those require candidate-specific evaluation. Planning revisions do not grant movement authority.
Each corridor still needs its own demand, terrain, climate, geotechnical, utility, accessibility, transfer, power, rescue and procurement assessment. A common vehicle and precast family can reduce manufacturing complexity without proving that every city needs the same formation or service pattern.
./install.sh
./osr status
./osr readiness
./osr workbench
./osr plan --help
./osr twin export
./osr design railway plan
./osr design railway run --max-bundles 2 --native-jobs 1
./osr design railway publish
./osr design railway verify
./osr build
./osr verify
./osr book --check
./osr test
./osr sim baghdadThe Workbench shows the factory draft inputs and open holds. Without a verified planning handoff, its compiler reports a hold and creates no package.
The coordinated run is bounded and restartable; it preserves pending work and failed executions. Native FEM/CAD workers need the relevant installed tools and declared resources. ./osr sim baghdad reports the current city-evaluation hold. ./osr build refreshes the current source-bound dossier, delivery drafts, Workbench and reader. The local review UI has no live train-control authority.
| I want to… | Start here |
|---|---|
| Understand the whole project | Overview, architecture, first adoption path |
| Review the selected train and open engineering | Current dossier, implementation, roadmap |
| Generate and compare new designs | Coupled experiment, design engine |
| Inspect city geography or planning proposals | Current city register, city catalogue, planning UI |
| Review CAD, BIM, BOM and manufacturing | Reference exports, candidate delivery packages |
| Follow the end-to-end workflow and calculated costing | Workflow above, cost formula above, implementation plan |
| Inspect current candidate delivery exports | Current export manifest, candidate delivery packages, ./osr twin export |
| Configure business and people workflows | ERPNext/Frappe HR deployment |
| Inspect supervision and maintenance integration | FUXA/gateway deployment, ERPNext lifecycle app |
| Work on controls or electronics | Rust packages, v0.6 control interfaces |
| Set up tools or contribute | Tools, CONTRIBUTING, GOVERNANCE, project instructions |
Hayder Aziz initiated OpenSourceRail. His published work on engineering design systems dates back more than 20 years. Beginning in the early 2000s, he researched how product data management, manufacturing knowledge, open standards and collaborative software could be joined into a coherent design process, enabling engineering teams to assess manufacturability and exchange design knowledge from the conceptual stage rather than treating design and production as separate activities.
Among his research publications are New Technologies and Standards for Design Knowledge Management in Collaborative Conceptual Design (2003, with James Gao, Paul Maropoulos and Wai Ming Cheung), Open standard, open source and peer-to-peer tools and methods for collaborative product development (2005, Computers in Industry), and Engineering design knowledge management in de-centralised virtual enterprises (2008, Computer-Aided Design and Applications). These works investigated reusable engineering knowledge, distributed product-development systems and the integration and automation of design-related workflows.
OpenSourceRail carries that research direction into an ambitious open transport-system project. The aim is to connect requirements, alternative generation, material selection, CAD/BIM, weight and cost calculations, supplier evidence, assembly methods, operational simulation and safety analysis in a traceable toolchain. This is the project's design philosophy and research ambition; the current railway candidates remain in development, without completed physical validation or certification for passenger operation.
| Concern | Source to change |
|---|---|
| Selected v0.6 requirements and assembly | Development selector, station-rail inputs and generators |
| Functional remit, design grammar and campaign budgets | Design-search source, campaign definitions |
| City inputs and geographic proposals | Each city's city.json under cities/catalogue/; current service outputs remain held |
| Controls and simulation behaviour | Rust crates, their tests and candidate-specific physical adapters |
| Business and equipment integration | ERPNext app, supervision deployment, integration service |
| System boundaries and remaining work | Architecture, roadmap, engineering instructions |
Regenerate derived artifacts from their current sources. Physical candidate, evaluation and selection identities are distinct; a source hash identifies bytes and does not approve engineering. ./osr verify checks the current source-bound publication, and ./osr twin export verifies the selected candidate's delivery exports. Neither command grants engineering, manufacturing or operating acceptance.
Contributions can improve supplier/material evidence, structural and motor models, complete equipment, manufacturing and repair methods, city data, controls, tests and documentation. Follow CONTRIBUTING.md and GOVERNANCE.md. The documentation index is a search aid; it is not another engineering authority.
Software uses Apache 2.0, open physical designs use CERN-OHL-S v2, and documentation uses CC-BY-SA 4.0, subject to more-specific and upstream notices. See LICENSE.md and LICENSES/.