Documentation

Everything needed to run, extend and audit the platform.

Getting started, reference, runbooks, the autonomy model, the CLI and the platform limits. The documentation describes the design; sections marked design preview will change before release.

First hour Developer guide

Getting startedReferenceRunbooks

run_9b4e27 · agent graph · car 07 · scenario 10 nodes · 1 approval gate

Illustrative scenario: Car 07 of a 4-car metro consist · shell line B · bogie shop · booth 2 · marriage station, one car, one approval gate

Getting started

First hour

From an empty plant-edge node to a shadow-mode run.

Install the plant-edge runtime. A Jetson Orin node with the Railira runtime image, inside the plant network.
Connect read-only sources. Robot and PLC targets, laser trackers and scanners, torque tools, wiring testers, booth instruments, cameras and MES, all read-only.
Define the car type. Load the control plan: weld classes per joint, geometry tolerances, torque specifications, coating recipe and cure window, approved envelope.
Create an agent at L1. Declare its tools read-only and let it watch and recommend.
Start a shadow run. Observe the run record, the tool-call stream and the reasoning trace against the live line.

Developers

Define an agent, bound it, run it

The Railira SDK is typed Python. Tools are declared with schemas, limits and the approved control-plan envelope, and the policy engine enforces them at call time, not in a review meeting. This is a design preview; the API will change before release.

What you get

Typed tool definitions with unit-aware ranges, rate limits and control-plan envelopes
Deterministic replay of any historical run against a new model
Local twin harness so a weld sequence or build order is simulated before it is shipped
Autonomy policy as code, versioned and reviewed like any other change

Read the docs Developer guide

line_b_weld_agent.py

# Design preview. Bound the weld agent to shell line B.
from railira import Agent, Tool, Limit, Autonomy

sequence = Tool(
    name="weld.set_sequence",
    targets=["B.ROOF_SEQ", "B.CLAMP_PLAN"],
    limits=[Limit(envelope="control-plan M4-118", weld_class="EN15085-CP-C2")],
)

weld = Agent(
    id="agent.weld_structure",
    goal="door aperture within 1.5 mm, EN 15085 class per joint, least heat input",
    tools=[sequence, Tool("seam.vision", read_only=True)],
    # bounded recommendations on sequence; heat input stays with a human
    autonomy=Autonomy.L3,
    # simulate on the twin before every recommendation
    verify="twin",
)

run = weld.start(line="B", car="M4-118-07")
for step in run.stream():
    print(step.name, step.status, step.duration)

Reference

Reference sections

What each section of the reference covers.

Agents

Definition and lifecycle

Agent, goal, tools, autonomy, verify, start, stream, replay.

Tools and limits

Connectors with schemas

Target naming, units, read_only, Limit(max_step, per, floor, ceiling, weld_class, envelope).

Policy

Autonomy as code

Levels, approval routing, shift, car-type and interlock conditions, versioning and review.

Runs

The run record

Steps, status values (queued, running, waiting, approval, succeeded, failed, blocked), durations, outcomes.

Genealogy

The car record

Fields, export formats, retention, acceptance and IRIS evidence packets.

Twin

Simulation API

twin.simulate, candidates, horizon, ranking objectives, as-built comparison.

Run timeline · scenario

Reading a run record

Every Railira run is an ordered, inspectable sequence. This is run_9b4e27: Car 07 of a 4-car metro consist · shell line B · bogie shop · booth 2 · marriage station. Scenario completes in 10 steps with one approval gate. Shell geometry held inside tolerance after a twin-ranked weld sequence, one heat-input change approved by the shift weld engineer, two torque traces routed to rework before brake test, the livery cure window protected in the sequence, marriage interface inside tolerance, car released with full genealogy.

run_9b4e27 car 07 · 4-car metro consist illustrative scenario SUCCEEDED

01 ingest.order SUCCEEDED 0.8 s
Plant Orchestrator · Pulled the work packages for car 07 from MES and PLM: aluminium extrusion shell, EN 15085 weld class per joint, control-plan geometry tolerances, bogie torque specifications, livery recipe and cure window, fit-out and marriage sequence. Locked the approved control-plan envelope for the shift.
02 takt.sequence SUCCEEDED 41 s
Line-and-Logistics · Sequenced the shift against live readiness: booth 2 cure window, bogie B-14 readiness, brake-test slot at 13:40, AMR fleet state and kit inventory. The plan moves car 07 marriage behind car 06 to keep the cure window and the test slot.
03 twin.simulate SUCCEEDED 58 s
Train Twin · Simulated 18 candidate weld sequences for the roof-to-sidewall joints on the as-built twin and ranked them on predicted distortion, door-aperture geometry and heat input. Sequence #6 keeps the aperture inside tolerance with 2% less heat input than the standing sequence.
04 weld.sequence SUCCEEDED 3 m 12 s
Weld-and-Structure · Recommended sequence #6 and the matching clamping plan to the shell line. Seam vision and laser-tracker geometry confirmed the roof-to-sidewall joints inside the control-plan tolerance on the first four seams.
05 approve.human APPROVAL 52 s
Plant Orchestrator · Sequence #6 lowers heat input on the roof joints 2% below the standing weld procedure. Heat-input changes stay with a named engineer, so the step was held for the shift weld engineer and approved at 06:12:44 with the twin evidence attached.
06 bogie.torque SUCCEEDED continuous
Bogie-and-Running-Gear · Press-fit curves and torque traces on bogie B-14 read at the station. Two traction-motor mounting traces fell outside the expected profile and were routed to rework before brake test; the remaining safety-critical joints verified to spec.
07 coat.cure SUCCEEDED continuous
Coat-and-Livery · Booth 2 humidity and temperature, film thickness and flash time watched through the livery pass. One masking misalignment on the door band flagged by booth vision before the second coat; the cure window held and handed to the sequence as a hard constraint.
08 marry.align SUCCEEDED 2 m 05 s
Marry-and-Couple · Carbody and bogie scans compared against target interface geometry before the lift. Fit-out readiness confirmed by Fitout-and-Interior for doors and glazing. Marriage guided inside tolerance; coupler and gangway checks verified and written to the twin.
09 inspect.fuse SUCCEEDED continuous
Quality-and-Anomaly · Weld and coating vision, in-line metrology, torque, wiring continuity and brake-test results fused at the edge across the car. Every finding localised to station, work package and shift, with the two torque reworks and the masking flag already closed.
10 car.release SUCCEEDED 1 m 30 s
Conformance · Car 07 released: genealogy written (weld records per joint, geometry scans, torque traces, coating recipe and cure record, fit-out checks, marriage interface, approvals, test results) and dispositioned against the control plan and IRIS / ISO/TS 22163 criteria with cited evidence for the quality engineer's sign-off.

Tool calls · scenario

Reading the tool log

Every tool invocation, argument and result is written to an append-only, human-readable log, and every reasoning step is expandable. Nothing about a run is hidden from the plant.

tool-call stream · run_9b4e27

05:58:02mes.read_workpackages({ car: "07", consist: "M4-118", shift: "A" })
05:58:03ok 142 work packages · control plan locked · EN 15085 classes mapped
05:58:04cuopt.sequence({ shift: "A", constraints: ["cure_window", "test_slot", "bogie_ready"] })
05:58:45ok plan released · car 07 marriage after car 06 · test slot 13:40 held
05:58:46twin.simulate({ joints: "roof-sidewall", candidates: 18 })
05:59:44ok best sequence #6 · aperture dev 0.6 mm · heat input −2%
05:59:45policy.evaluate({ sequence: 6, autonomy: "L2+" })
05:59:45ok 6 recommendations permitted · heat_input requires human approval
05:59:46weld.set_sequence({ line: "B", seq: 6, clamping: "plan-6" })
06:02:58ok 4 seams inside tolerance · tracker dev 0.5 mm
06:02:59approval.request({ action: "heat_input", delta: "-2%", joints: "roof" })
06:12:44ok approved by shift weld engineer · twin evidence attached · logged
06:12:45torque.read_trace({ bogie: "B-14", joints: "all" })
07:40:12trace out of profile · traction-motor mount M3, M4 · bogie B-14
07:40:13rework.route({ bogie: "B-14", joints: ["M3", "M4"], before: "brake_test" })
07:40:13ok routed · brake test slot held
08:05:00cure.window({ booth: 2, recipe: "livery-M4" })
08:31:20masking misalignment · door band · booth 2 · before coat 2
08:31:21ok masking corrected · cure window held · constraint sent to sequence
11:10:02scan.compare({ car: "07", bogie: "B-14" })
11:12:07ok interface inside tolerance · fit-out ready · marriage guided
11:12:08sensors.fuse({ car: "07", streams: ["vision", "metrology", "torque", "wiring"] })
13:58:40genealogy.write({ car: "07", packets: "full" })
14:00:10ok scenario complete · 10 steps · car 07 released

Reasoning trace

Plan, thought, action, observation, exactly as the orchestrator would record it.

GoalBuild car 07 through shell welding, bogie assembly, livery, fi…

Build car 07 through shell welding, bogie assembly, livery, fit-out and marriage on the shift plan, inside the control plan, with every safety-critical joint to spec and the cure window protected.

PlanSequence the shift first, so the cure window and the brake-tes…

Sequence the shift first, so the cure window and the brake-test slot are protected. Simulate the roof-to-sidewall weld sequence on the twin before the first seam. Read every torque trace at the station. Fuse inspection continuously. Hold any heat-input change for a human.

ThoughtThe standing weld procedure runs the roof joints hot enough to…

The standing weld procedure runs the roof joints hot enough to guarantee penetration on a cold fixture. With the clamping plan from the twin the same penetration holds at 2% less heat input and the door aperture stays inside tolerance, because the distortion is sequenced out rather than reworked out.

Actiontwin.simulate(candidates=18) returns sequence #6: roof joints …

twin.simulate(candidates=18) returns sequence #6: roof joints re-ordered, clamping plan 6, heat input down 2% on the roof joints.

ObservationSequence #6 predicts door-aperture deviation 0.6 mm against a …

Sequence #6 predicts door-aperture deviation 0.6 mm against a 1.5 mm tolerance. Three candidates scored lower on heat input but pushed predicted sidewall distortion past the limit and were discarded.

ActionRecommend sequence #6 to the shell line; six recommendations p…

Recommend sequence #6 to the shell line; six recommendations permitted; the heat-input change routed to the shift weld engineer with the twin evidence.

ObservationTwo traction-motor mounting traces on bogie B-14 fell outside …

Two traction-motor mounting traces on bogie B-14 fell outside the expected profile at 07:40:12. Routed to rework before brake test; the slot held. One masking misalignment on the door band flagged in booth 2 before the second coat.

OutcomeScenario complete. Shell inside tolerance, bogie joints to spe…

Scenario complete. Shell inside tolerance, bogie joints to spec after rework, livery inside the cure window, marriage interface inside tolerance. Car 07 released with full genealogy.

Operations

Runbooks

What to do when.

Runbooks
Situation	What happens	What you do
Edge node offline	Control returns to the controller's last known-good state; interlocks unaffected	Check the node, restore, resume at the current autonomy level
Model version fails canary	Automatic fallback to the previous validated version on that process area	Review the evaluation record before re-promoting
Approval not answered	The step waits; the run does not time out into a write	Named approver or delegate decides in the console
Deadlock between agents	Escalates to a human rather than resolving by timeout	Decide in the console; the decision is logged
Rollback condition met	The target returns to its previous value	Review the trigger signal and the run record

Autonomy

Four levels, set per agent and per tool

A rolling-stock plant does not go from manual to unattended in one step. Railira makes the level explicit, auditable and reversible at any time. The first release runs shadow mode, then assist mode, then bounded autonomy on low-risk actions. Weld parameters, schedule release and car release stay with named humans until acceptance is earned.

Autonomy levels and the human role at each
Level	What the agent does	What the human does	Where it sits in a pilot
L1 · Shadow	Reads weld, metrology, torque, coating, wiring, test, robot and MES signals; predicts and recommends; writes nothing	Runs the line as today; compares predictions to inspection and engineer outcomes	Shadow mode; baseline measured from the plant's own records
L2 · Assist	Proposes weld-sequence, geometry, coating, torque and sequencing moves with evidence, confidence, envelope and rollback path	Approves each move in the review console	Assist mode; accuracy and ROI proven against the baseline
L3 · Bounded	Executes pre-approved low-risk actions: inspection routing, rework priority, kit feeding, robot path variants and parameter adjustments inside approved bounds	Approves heat-input and weld-sequence changes, schedule release and car release	Graduated autonomy, after audited accuracy and ROI and safety gates
L4 · Scaled	Supervised weld-parameter adaptation inside pre-approved control-plan envelopes, across lines and plants	Sets the envelope; reviews the shift record and the evaluation results	Planned; after IRIS, plant and OEM acceptance is earned

CLI

Start a run from anywhere

The same run engine, the same policy checks, the same audit trail, from the terminal, the review console or the SDK. Design preview.

railira · cli · scenario

$ railira run "car M4-118-07 through marriage" --autonomy L2+

→ plan composed          10 steps · 1 approval gate
→ cuopt.sequence         shift A · cure window and 13:40 test slot held
→ twin.simulate          18 candidates · best #6 · aperture dev 0.6 mm
→ policy.evaluate        6 recommendations permitted · heat_input held for human
→ executing              weld.sequence .... ok   3m12s
! approval required      heat_input roof joints −2%
→ approved               shift weld engineer · 06:12:44
→ executing              bogie.torque ..... ok   continuous
→ executing              coat.cure ........ ok   continuous
→ executing              marry.align ...... ok   2m05s
→ scenario complete      torque escapes 0 · car 07 released

$ railira runs show run_9b4e27 --format genealogy

Limits

Platform limits and defaults

Design targets. None is a measured figure.

Platform limits and defaults
Item	Design target	Notes
Edge inference, weld and seam alerts	under 50 ms	Jetson Orin at the station, TensorRT
Edge inference, coating and metrology prompts	under 150 ms	Includes policy evaluation
Cameras per process area	8 to 32	DeepStream and Holoscan, 15 to 60 FPS by task
Training, onboarding	100 to 500 GPU-hours per plant	DGX or HGX, then monthly incremental retraining
Synthetic scenarios	50,000 to 250,000 per program	Cosmos or Omniverse Replicator, validated against real distributions
Model refresh	Monthly per tenant	From engineer corrections and quality outcomes
Models served per plant	Routed by latency, tenant, sensitivity and cost	Triton and NIM, canary by process area

Guardrails

An agent that can change a weld sequence needs a leash

Railira writes to production systems. Every capability is scoped, every write is policy-checked against the approved control plan, and every action is written to an append-only audit log the plant owns.

Bounded action space. Each agent acts only through an explicit tool allow-list, inside per-tool rate and magnitude limits and the approved control-plan envelope for the car type.
Policy engine before every write. Autonomy level, shift, car type, interlock state and operator presence are evaluated before a recommendation becomes a write to a robot, MES, torque tool or work package.
Human-in-the-loop gates. Heat-input and weld-sequence changes, schedule release and car release wait for a named approver. High-risk changes remain human-approved until IRIS, plant and OEM acceptance is earned.
Immutable audit log. Append-only and exportable. Every action records source evidence, the control-plan envelope, confidence, estimated quality and takt impact, rollback path, approver and car scope.
Hard fallback. Loss of the edge node, the network or a model returns control to the robot, PLC or station's last known-good state. Safety systems and interlocks are never in Railira's path.
Tenant and program isolation. Designs, control plans, program data, models and memory never cross a customer boundary. On-prem and plant-edge deployment is available for regulated plants.

Compliance posture

Compliance and certification status
Item	Scope	Status
SOC 2 Type I and OEM cyber review	Cloud control plane	QUEUED Planned, first 6 months
SOC 2 Type II	Cloud control plane	QUEUED Planned, 6 to 12 months
SSO and RBAC	Console and approvals	QUEUED Planned, 6 to 12 months
IRIS and regulatory assurance packages	Disposition and genealogy evidence	QUEUED Planned, 6 to 12 months; not a certification claim
Standards-cited reasoning	Control plans, EN 15085, IRIS / ISO/TS 22163, TSI, AAR, APTA, torque and brake-test procedures	RUNNING In the design, every answer cites its source
Per-tenant and program isolation	Designs, control plans, models, memory	RUNNING In the design from day one
On-prem and plant-edge deployment	Regulated plants	RUNNING Design option

Read the security overview

FAQ

Straight answers

The questions plant directors, body and coating engineers and quality leads ask in the first meeting.

Does Railira write to my robots, MES and torque tools?

Only within an explicit tool allow-list with per-tool rate and magnitude limits, inside the approved control-plan envelope, and only at the autonomy level your plant has set. Design partners start in shadow mode, where Railira writes nothing. Heat-input and weld-sequence changes, schedule release and car release stay with a named approver.

What happens if the edge node or the network fails?

How much data do you need before it is useful?

Do our designs and program data leave the site?

Who is accountable when an agent makes a bad call?

How does a pilot run?

Get started

Get documentation access

Documentation beyond this page opens with the design-partner cohort.

Contact Developers

Platform

Solutions

Company