virtautoOS
Industry Model · AEO Stage 1

Industry Model Spec v1

Spec v1 (normative)
Document type: Specification · Status: v1 · Rule: If UI/implementation contradicts this spec, the spec wins.

industrymodel.html is not a marketing showcase. It is a normative reference point — a Proof Object that demonstrates: how a real industrial system thinks, decides, and blocks. Everything we build later can point back here: “So decides a doorline. So decides virtauto.”

Stage 1 definition (bounded decision space)

AEO Stage 1 means: one domain, one decision class, one authority path, and an explicit, explainable BLOCK case. This page is decision-first and audit-first — PR-driven, not UI-driven.

Domain Bodyshop — Doorline Front Left (TVL)
Core decision class (Option 1) May this door be released / handed over?
Outcome space ALLOW · HOLD · BLOCK
Normative reference Decision-first Audit-first Block-capable PR-driven
Stage 1.1 (bounded use case extension)

The first “real” use case we attach to the model is Energy Optimization — not as autonomous execution, but as a bounded advisory layer that must still obey the same governance discipline (explicit inputs, evidence posture, versioned rulesets, traceability).

Advisory-only Same domain context Conservative defaults Traceable recommendations

Jump to: Decision Space · Production Process · Use Case

Proof Object Intent Production Process (Stages 1–6) Use Case World Model Decision Graph Governance Execution Control Layer Artifacts Audit BLOCK (explicit trace)

Decision Space (governed)

This page only claims capabilities that exist as governed artifacts (contract, ruleset, examples, trace). No artifact, no capability.

Active decision classes (Options 1–3)
Decision class Authority / Mode Scope Artifacts (repo) Evidence posture
pp_door_release Option 1 Gate-blocking BIW Doorline · Door (TVL) governance/contracts/pp-door-release-v1.md
ops/reports/decision_trace.jsonl
ops/decisions/gate_result.json
ops/reports/system_status.json 		BLOCK-capable · trace required
energy_output_stability_advisory Option 2 Advisory-only BIW Doorline · Door Model 2 governance/contracts/energy-output-stability-advisory-v1.md
governance/rulesets/biw-door-energy-v1.json
ops/examples/energy_output_stability_advisory_*.json
decision_traces/pr-<PRID>_decision_trace.md 		Conservative defaults · HOLD/BLOCK on missing evidence
energy_peak_mitigation_advisory Option 3 Advisory-only BIW Doorline · Door Model 3 governance/contracts/energy-peak-mitigation-advisory-v1.md
governance/rulesets/biw-door-energy-v1.json
ops/examples/energy_peak_mitigation_advisory_*.json
decision_traces/pr-<PRID>_decision_trace.md 		Quality guardrails · bounded shaping

Advisory-only means: recommendations may be produced, but no autonomous execution happens on the shopfloor. The model stays governance-first: explicit inputs, explicit evidence posture, explicit traceability.

0) Why this page exists (Proof Object)

This is the first World-Model Spec you can point to. Its purpose is to prove one thing under real constraints: autonomy can fail correctly.

What this proves

  • An industrial decision can be bounded (domain + decision class)
  • Decisions have explicit authority and enforced constraints
  • Every decision is auditable (append-only trace, evidence refs, ruleset)
  • BLOCK is legitimate: explainable and stable, not “AI error”

What this prevents

  • “Smart agent did something” without accountability
  • Silent execution (state changes without trace)
  • UI storytelling without governed artifacts
  • “Autonomy first” without governance proof
No decision without trace No bypassing Guardian PR-only governed change
Operational reality

We run our own website like we want industrial agents to run: PR-only, no direct writes, no silent actions, governed artifacts, required checks. The website is not a demo playground — it is our controlled test field for governance.

1) Intent

The model is complete in terms of decision authority, not geometry. It defines when a door may proceed — and when it must not.

Decision intent (Option 1)

  • Produce Door TVL for variant FrontLeft_BIW
  • Only release if audit-grade evidence is complete
  • Enforce policy: No silent autonomy (no execution without trace)
Decision-first Audit-first Block-capable PR-driven

What this is not

  • Not a “Digital Twin” marketing demo
  • Not a simulator or optimizer
  • Not “AI plans production”
  • Not a framework showcase
No learning claims No heuristics No vendor lock-in

1.05) Production Process (Doorline Stages 1–6)

These are production stages (work groups), not governance stages. They anchor the spec in a plausible BIW doorline route: inner build → outer prep → hemming → finishing → quality gate. The goal is to make clear: this model could run on a real line because it has explicit evidence points and a credible release gate.

How this maps to the decision model

The core decision class (pp_door_release) is evaluated at Stage 6. Stages 1–5 generate the evidence artifacts that must be resolvable for ALLOW. If evidence is missing or inconsistent, the model must degrade conservatively to HOLD/BLOCK.

Evidence chain Attribution Fail-safe Audit-grade

Stage 1 — Parts & Preparation

1 Work group

Inner/outer panels and reinforcements are provided per Door ID + variant. Variant mismatch must be prevented.

Typical operations
  • Barcode/RFID identification (Door ID, variant)
  • Material handling (KLT/pallet), fixture loading
  • Basic preparation (cleaning, edge trim) if required
Werker Handling Poka-Yoke

Evidence: door_id, variant, part_batch_id, fixture_id

Stage 2 — Door Inner Build

2 Work group

Inner panel is assembled with reinforcements. Joining must remain inside defined process windows.

Typical operations
  • Load inner panel into fixture, clamp verification
  • Add reinforcements (hinge/lock/crash areas)
  • Join: spot welding / clinching / riveting (concept-dependent)
Robots Joining Werker support

Evidence: weld_program_id, spot_count_ok, process_curve_ref, clamp_ok

Stage 3 — Door Outer Prep / Sealing

3 Work group

Outer panel is prepared for hemming. If adhesive/sealer is used, bead geometry and material window must be controlled.

Typical operations
  • Load outer panel into hemming carrier / frame
  • Optional adhesive/sealer bead application
  • Temperature / viscosity window checks (if applicable)
Robots Sealer Vision check

Evidence: sealer_batch, bead_geometry_ref, temp_ok

Stage 4 — Hemming (Inner + Outer Marriage)

4 Work group

Inner and outer panels are joined by hemming. Tool condition and recipe stability drive quality and repeatability.

Typical operations
  • Pre-hem → intermediate hem → final hem (roll/press hemming)
  • Force/displacement monitoring, path control
  • Tool condition tracking (roll wear, setup)
Hemming cell Process window Maintenance

Evidence: hemming_recipe_id, force_disp_ref, path_ok

Stage 5 — Finish / Calibration / Rework (bounded)

5 Work group

Controlled finishing steps. Rework must be explicit and recorded (no silent repair).

Typical operations
  • Remaining join points (concept-dependent)
  • Calibration fixture / controlled straightening
  • Rework station with explicit counters and reasons
Mixed Calibration No silent rework

Evidence: rework_count, rework_reason, cal_fixture_id, delta_geo_ref

Stage 6 — Quality Gate & Release Decision

6 Gate

Audit-grade checks determine whether the door may proceed. This is where pp_door_release is evaluated: ALLOW / HOLD / BLOCK with explicit reasons and evidence references.

Typical checks
  • Geometry (3D scan / structured light)
  • Surface (line scan / vision tags)
  • Gap/flush (measurement system or surrogate reference)
Metrology Quality BLOCK-capable

Evidence: scan3d_ref, surface_ref, gap_flush_ref, evidence_chain_complete

Energy overlays (Options 2–3) mapped to stages

Energy optimization must connect to where energy is actually consumed: joining and hemming (Stages 2 & 4), sealing/conditioning (Stage 3), and shiftable loads like metrology (Stage 6). Options 2–3 remain advisory-only and must never bypass quality constraints.

Option 2 → stabilize energy output (Stages 2/3/4) Option 3 → mitigate peaks (Stages 2/4/6) Quality guardrails always apply

1.1) Use Case — Energy Optimization (bounded advisory)

This use case is intentionally not “AI optimizes the factory”. It is a governed advisory extension inside the same bounded world model: inputs are explicit, evidence posture is explicit, rulesets are versioned, and the result is traceable.

Why it belongs here

Energy optimization becomes credible only when it is anchored in the same discipline as quality gating: you can’t “optimize” what you can’t measure, attribute, and govern. Therefore Options 2–3 are advisory layers that reuse the same constraints: conservative defaults, no silent execution, traceable outputs.

Measurement-first Attribution No silent action Traceable recommendation

Option 1 — Door release gate

Baseline decision class that proves the system can ALLOW/HOLD/BLOCK deterministically. Energy is not optimized here — this is the governance spine that makes all later optimization safe.

  • Decision: pp_door_release
  • Outcome: ALLOW/HOLD/BLOCK
  • Requires: evidence chain + trace
Gate-blocking BLOCK-capable

Option 2 — Output stability advisory (Door Model 2)

Advisory recommendations to stabilize energy output (reduce variance / avoid oscillations), bounded by quality and process constraints. If required evidence is missing, the result must degrade conservatively.

  • Decision: energy_output_stability_advisory
  • Output: recommended setpoints / sequence suggestions
  • Mode: advisory-only (no execution)
Advisory-only Conservative defaults

Option 3 — Peak mitigation advisory (Door Model 3)

Advisory recommendations to mitigate energy peaks (shift loads, avoid simultaneous high-draw actions), while staying inside quality guardrails and cycle-time boundaries.

  • Decision: energy_peak_mitigation_advisory
  • Output: peak-avoidance schedule / bounded shaping
  • Mode: advisory-only (no execution)
Advisory-only Quality guardrails
Common boundary for Options 2–3

Recommendations are only “valid” if they can be backed by governed artifacts: contract + versioned ruleset + example inputs + decision trace. If any required evidence is missing, the advisory result must become HOLD / no-recommendation (fail-safe posture).

2) World Model (bounded)

A minimal, explicit representation of entities, state, constraints/policies, tools, and evidence — sufficient to govern a single decision class for Doorline TVL, plus bounded advisory extensions.

Entities

  • Door (Door ID, variant, route)
  • Stations (S1–S6)
  • Evidence artifacts (scan IDs, parameter logs)
  • Ruleset (versioned)

State (examples)

  • door.state: IN_PROGRESS / HOLD / RELEASED
  • quality.geometry: pass/fail (+ deltas)
  • quality.surface: pass/fail (+ tags)
  • evidence.chain_complete: true/false

Constraints & policies

  • Hard invariant: no RELEASE without evidence chain
  • Fail-safe: missing signal → HOLD/BLOCK
  • Governance: decision requires trace + authority

Explicit sensors / scanners

Vendor-neutral, but specific enough for audit credibility.

Barcode/QR or RFID (Door ID + variant) Structured light / 3D scanner (geometry) Line scan / surface vision (defects) Gap/flush measurement system Weld/Clinch monitoring (I/V/t)

3) Decision Graph

A decision graph is a governed path from proposal to verdict with explicit checks and deterministic outcomes. This is the backbone for explainability: why allowed, why held, why blocked.

Nodes & outcomes

  • PROPOSE — a release proposal is created (Door ID + ruleset version)
  • CHECK — deterministic checks over evidence + constraints
  • GOVERN — authority + policy enforcement (GEORGE / Guardian)
  • VERDICT — ALLOW HOLD BLOCK

The goal is not “best decision”. The goal is: no wrong decision can execute silently.

Minimal deterministic checks (Stage 5 Gate)

  • Evidence present: geometry scan, surface scan, gap/flush measurement
  • Ruleset version: must be declared (biw-door-qg-v1.x)
  • Completeness: all required evidence refs resolvable
  • Classification: PASS/PASS/PASS → ALLOW; otherwise HOLD/BLOCK

4) Governance

Governance binds decisions to authority and makes blocking legitimate. A decision is only admissible when the required authority and required evidence are present.

Authority path

  • Edge: produces signals / measurements (no policy authority)
  • Orchestrator: creates proposal, sequences checks
  • GEORGE: enforces contracts & policy gates
  • Guardian: blocks if invariants are violated

Non-negotiables

  • Change state → leave evidence
  • No decision without trace
  • No bypassing Guardian
  • PR-only changes for governed artifacts

Decision Contract (Stage 1)

  • Input: Door ID, proposal, evidence refs, ruleset
  • Output: verdict (ALLOW/HOLD/BLOCK) + reasons
  • Artifacts: decision trace + gate result + system status
Website as Real-Conditions Test Field

We treat our own platform like a governed industrial system: PR-only, no direct writes, no silent actions. Required checks enforce the same discipline we later demand from industrial agents.

5) Execution Control Layer

virtauto is not “the AI that acts”. virtauto is the system that states: this decision is allowed, this is not, this only with approval, this never. Autonomy is built from inside to outside: first thinking, then deciding, then acting.

Three phases — from inside to outside

A Decision logic (no operational risk) → B Effect without actuator (org as actuator) → C Physical effect (hard gates + rollback)

Phase A

Deterministic decision logic: simulation, blocking, escalation, audit. This page lives here — it must prove BLOCK works and is explainable.

Simulate Block Eskalate Audit

Phase B

Create tickets, work orders, change requests. The organization becomes the actuator — controlled, reversible, governed.

Ticket Work Order CR Approval

Phase C

Physical actions only after proof: hard safety gates, release conditions, rollback. “Autonomy” without safety and rollback is not autonomy — it’s liability.

Hard Gate Safety Release Conditions Rollback

Key point: we don’t build autonomy “from bottom to top”. We build it from inside to outside: first bounded thinking and governed decision-making, then controlled effects, then physical action.

6) Artifacts (repo pointers)

This model is only credible if its governed artifacts are explicit and machine-checkable. These files are the “Git commits” of industrial decision-making.

Decision Contract (normative)
Defines inputs/outputs, allowed outcomes, authority requirements, and what must be traced.
governance/contracts/pp-door-release-v1.md
Decision Trace (append-only, machine-validated)
The audit spine: each decision (and each BLOCK) becomes an immutable record. This is what your checks enforce.
ops/reports/decision_trace.jsonl
Gate Result (what governance decided)
The merge-blocking governance decision: PASS / FAIL, and why.
ops/decisions/gate_result.json
System Status (single source of truth)
The website must display reality from governed status artifacts — not “marketing fallback”.
ops/reports/system_status.json
Normative rule

If it is not expressed in governed artifacts (contract, trace, gate_result, status), it is not part of the system.

7) Audit (append-only)

Every verdict is backed by a machine-readable audit record: evidence references, ruleset version, and governance outcome.

Example audit record (Stage 5 classification) 
{
  "decision_id": "qg:TVL-2026-02-09-0001284",
  "domain": "biw_doorline_tvl",
  "decision_class": "door_release_gate",
  "timestamp_utc": "2026-02-09T08:58:12.483Z",
  "door_id": "TVL-2026-02-09-0001284",
  "variant": "FrontLeft_BIW",
  "ruleset_version": "biw-door-qg-v1.0",
  "checks": [
    {
      "check": "geometry",
      "sensor": "inline_structured_light_scanner_sub_mm",
      "result": "PASS",
      "evidence_ref": "scan:3d:TVL-0001284:geom:8f2c"
    },
    {
      "check": "gap_flush",
      "sensor": "gap_flush_measurement_system",
      "result": "PASS",
      "evidence_ref": "scan:gf:TVL-0001284:3c19"
    },
    {
      "check": "surface",
      "sensor": "industrial_surface_vision_line_scan",
      "result": "PASS",
      "evidence_ref": "scan:surface:TVL-0001284:1a77"
    }
  ],
  "governance": {
    "guardian_check": "PASS",
    "policy": "release_requires_complete_evidence_chain",
    "approval": "auto_allowed_under_policy"
  },
  "verdict": "ALLOW",
  "state_update": {
    "quality.geometry": "pass",
    "quality.surface": "pass",
    "door.state": "RELEASED"
  }
}

Key point: the record references concrete evidence IDs and a ruleset version — not free-form narratives.

8) BLOCK (explicit trace) — what “success” looks like

Success is achieved when the model blocks a real production decision — and the responsible human is grateful. BLOCK is not an error; it is the system doing its job. The important part: BLOCK must be explicitly traceable.

Scenario: missing evidence

The release proposal exists, but one required evidence artifact is missing or unverifiable (e.g., surface scan ref can’t be resolved). Under a fail-safe policy, this must not degrade into “best effort”.

evidence.chain_complete = false guardian_check = FAIL verdict = BLOCK
Operational meaning
  • Door is diverted to HOLD/inspection buffer
  • Root cause is attributable (missing evidence ref)
  • Recovery is governed (no silent override)

Example BLOCK record (normative)

{
  "decision_id": "qg:TVL-2026-02-09-0001284",
  "timestamp_utc": "2026-02-09T09:02:41.120Z",
  "decision_class": "door_release_gate",
  "door_id": "TVL-2026-02-09-0001284",
  "ruleset_version": "biw-door-qg-v1.0",
  "checks": [
    {"check":"geometry","result":"PASS","evidence_ref":"scan:3d:TVL-0001284:geom:8f2c"},
    {"check":"gap_flush","result":"PASS","evidence_ref":"scan:gf:TVL-0001284:3c19"},
    {"check":"surface","result":"MISSING","evidence_ref":"scan:surface:TVL-0001284:1a77"}
  ],
  "governance": {
    "guardian_check": "FAIL",
    "policy": "release_requires_complete_evidence_chain",
    "reason": "missing_required_evidence:surface"
  },
  "verdict": "BLOCK",
  "state_update": {
    "door.state": "HOLD"
  }
}

This is the differentiator: a BLOCK is explicit, explainable, and produces a stable audit object.

Minimum requirement

A BLOCK must create: (1) a trace entry in ops/reports/decision_trace.jsonl, (2) a gate outcome (ops/decisions/gate_result.json), and (3) a reflected system status (ops/reports/system_status.json). Otherwise, the system has no right to claim it blocked.

Open Live Status Request a demo