Mapping the governance gap in construction robotics and AI-powered manufacturing to 10 SWT3 witness procedures across three distinct liability boundary models.
Who this is for: Manufacturing safety officers, construction project managers, building inspectors, Notified Bodies evaluating AI-operated machinery, product liability attorneys, robotics company compliance teams, and insurers underwriting AI-fabricated structures.
EU Machinery Regulation 2023/1230 takes effect January 20, 2027. AI-driven manufacturing equipment with safety functions or self-evolving behavior requires third-party conformity assessment. Anthropic's Model Hardware Standard (MHS) is standardizing how AI agents operate physical devices. The construction robotics market is projected to reach $14.82 billion by 2036. No company in this space has published a governance framework for AI-driven physical manufacturing.
It is 7:14 AM in Metro Phoenix. A robotic factory module receives a CAD file from a homebuilder's design team, runs it through an AI translation model, and generates 847 manufacturing instructions. Six hours later, a finished wall panel ships to a subdivision. The AI decided the stud spacing, the nailing pattern, the sheathing cut geometry, and the moment each pneumatic fastener fired. The building inspector who signs off on the framing has never seen the model that made those decisions, has no way to verify which version of the model was running, and has no evidence chain linking the AI's output to the structural code requirements the panel must satisfy. Nobody governed the inference. The panel is already on the truck.
This is not hypothetical. In October 2026, America's largest homebuilder signed a multi-year commercial agreement with a Canadian robotics firm for AI-powered production of over 1,250 homes using KUKA industrial robotic arms. The robotics company operates the factory (a 16,000 sq ft facility in Gilbert, Arizona, serving multiple homebuilders) and the AI. The builder supplies designs and takes delivery of finished components. Production starts early 2027 -- in a jurisdiction that currently enforces the 2018 IRC, two editions behind the current 2024 publication. At the same time, the EU Machinery Regulation takes effect on January 20, 2027, classifying AI-driven manufacturing equipment as a named category requiring mandatory third-party conformity assessment. Anthropic's Model Hardware Standard (MHS), announced August 2026, is standardizing how AI agents read from sensors and write to actuators across industrial equipment. The Robotics-as-a-Service market is valued at $2.83 billion in 2026 and projected to reach $14.82 billion by 2036 at 18% CAGR.
The market is accelerating. A Swiss autonomous excavator startup raised $200 million in August 2026 at a $1 billion valuation. An Amsterdam-based company has deployed over 150 autonomous bricklaying machines across 100+ homes. A UK micro-factory startup deploys shipping-container manufacturing cells directly on construction sites. And one of the earliest entrants -- a company that raised $58 million for end-to-end robotic homebuilding -- shut down in December 2024 after failing to demonstrate unit economics, its assets auctioned off in lots. Capital is flowing in, companies are failing, and not one company in this space has published a governance framework. A Construction Executive survey found that 79% of construction company boards have approved AI spending, but only 40% have any formal AI governance policy.
The question is not whether physical AI will be governed. The Machinery Regulation, product liability law, and building codes guarantee that it will. The question is whether governance evidence exists at all when the regulator, the insurer, or the plaintiff's attorney comes looking. This guide maps the governance gap in AI-driven physical manufacturing and construction to the SWT3 witness procedures that fill it -- across three distinct liability boundary models that no other framework has addressed.
Physical AI manufacturing sits at the intersection of multiple regulatory regimes that are converging simultaneously. None of these frameworks were designed with AI-operated factories in mind, but all of them apply.
| Regulation / Standard | Effective Date | Physical AI Impact |
|---|---|---|
| EU Machinery Regulation 2023/1230 | January 20, 2027 | Machinery with "fully or partially self-evolving behaviour using machine learning approaches ensuring safety functions" (Annex I, Part A, Items 5-6) requires mandatory third-party conformity assessment by a Notified Body -- no self-assessment exception. Article 18 "substantial modification" applies to any digital change that affects safety. The Digital Omnibus (Reg. 2026/1744, July 2026) moved the Machinery Regulation from AI Act Annex I Section A to Section B, giving sector-specific machinery rules priority over AI Act Chapter III. |
| EU Product Liability Directive 2024/2853 | December 9, 2026 | AI software is now a "product" (Article 4). Transposition deadline December 9, 2026 (corrigendum: products on market on or after that date are covered). Three rebuttable presumptions shift the burden of proof. Article 7(2)(c) requires courts to consider the AI's ability to "continue to learn" post-placement. Article 11 eliminates the development risk defense for software updates. Only 3 of 27 member states have transposed as of October 2026. |
| ISO 10218:2025 | Published 2025 | Robot safety standard now includes cybersecurity requirements for the first time (Clause 5.1.16: documented threat assessment mandatory). Harmonized under EU Machinery Directive via OJ citation September 7, 2026. New Class I/II robot classification. ISO/TS 15066 collaborative operation content absorbed into Part 2. AI-based safety functions must meet Performance Level (PL) per ISO 13849 -- the standard acknowledges AI presents new risks but defers to existing functional safety frameworks. |
| Model Hardware Standard (MHS) | Research preview Aug 2026 | Standardizes AI agent control of physical devices via two primitives: read (sensors) and write (actuators). Built on MCP. Every device driver stores safety limits and physical characteristics. Compatible with any AI model. |
| International Building Code (IBC/IRC) | Adopted by jurisdiction | Structural requirements for load-bearing elements, fastener spacing, material grades. Building inspectors must verify compliance regardless of whether a human or AI determined the construction parameters. |
| OSHA 29 CFR 1926 | Active | Construction safety standards apply to any job site where AI-fabricated components are installed. Frequent inspection requirements (1926.20) do not distinguish between human-built and AI-built structures. |
Harmonised standards gap: As of October 2026, the full batch of harmonised standards cited under the new Machinery Regulation 2023/1230 has not yet been published (expected Q4 2026). Without cited standards, Part B manufacturers cannot use the self-assessment route and must involve a Notified Body. Part A manufacturers (AI/ML safety components) require a Notified Body regardless. The 2027 I-Codes will formally incorporate ICC/MBI 1200, 1205, and 1210 for offsite construction -- the first building code framework for factory-built components -- aligning with the same quarter as the Machinery Regulation's application date.
The convergence problem: A single AI-fabricated wall panel may need to satisfy the Machinery Regulation (the factory that built it), ISO 10218 (the robots that handled it), the IBC (the structural code it must meet), OSHA (the site where it was installed), and the Product Liability Directive (if anyone is harmed by a defect). No single regulatory framework covers the full chain. SWT3 witness anchors provide a unified evidence trail across all of them.
The governance challenge in AI-driven manufacturing depends on who owns the factory, who owns the AI, and who takes delivery of the physical output. Three distinct models are emerging in the market, each creating a different answer to the question: who is liable when an AI-fabricated component fails inspection?
Structure: The robotics company owns and operates a centralized manufacturing facility. The builder supplies design files and receives finished components. The factory's AI translates designs into manufacturing instructions, and robotic systems execute them. The builder never touches the AI or the robots.
Liability split: The factory operator is the manufacturer of the machinery product (the factory system and its AI). The builder is the customer. The AI's manufacturing decisions are the factory operator's responsibility. But the builder bears building code liability for the finished structure.
Governance gap: The builder has no visibility into which model version made decisions about their designs. No evidence chain links the design file to the manufacturing instructions to the physical output. If a panel fails inspection, the builder cannot prove what the AI did or did not do -- they can only point at the factory operator.
Key SWT3 procedures: AI-DEL.1 (delegation from builder to factory AI), AI-PROV.1 (model provenance for each fabrication run), CON-INS.1 (inspection attestation for finished components), HBOM-INV.1 (factory cell hardware inventory).
Structure: The robotics company deploys compact manufacturing units (often housed in shipping containers) directly on the builder's construction site. The robotics company owns the equipment and operates the AI. The builder owns the site, controls site conditions, and takes delivery of output on-site.
Liability split: More complex than the centralized model. The micro-factory is the robotics company's machine, but it operates in the builder's physical workspace. Under EU Machinery Regulation Article 18, if the builder adjusts any AI parameter -- even a design tolerance -- the builder could become the legal manufacturer of a machine they did not build.
Governance gap: Physical proximity creates ambiguity. Who controls the AI when the factory is on your site? Who is responsible for environmental conditions (temperature, humidity, vibration) that affect component quality? If the builder's electrician plugs the micro-factory into an unstable power supply and a panel comes out defective, the root cause is environmental -- but the AI's output is what the inspector evaluates.
Key SWT3 procedures: CON-ENV.1 (environmental monitoring at the deployment site), AI-CHAIN.1 (multi-device orchestration within the micro-factory cell), AI-DRIFT.1 (detecting behavioral changes when a factory unit moves between sites), CON-STR.1 (structural verification against code).
Structure: The builder purchases or leases robotic manufacturing equipment. The robotics company's AI runs on the builder's hardware, making real-time fabrication decisions. The builder owns and operates the physical machine. The AI provider controls model updates, training data, and inference logic.
Liability split: The builder is the machine operator. The AI provider is the software supplier. Under the Product Liability Directive, the entity whose AI "substantially modifies" the machine's behavior bears product liability. Every model update the AI provider pushes to a builder-owned robot is a potential substantial modification event.
Governance gap: The builder owns the robot but has no control over the AI running on it. The AI provider controls the AI but has no control over the physical workspace, maintenance schedule, or operating conditions. Neither party has complete governance. An OTA model update that changes collision avoidance behavior by 3 centimeters could turn a validated robot into a non-compliant one overnight -- and neither party may notice.
Key SWT3 procedures: AI-MDL.2 (model version governance for every OTA update), AI-SAFE.1 (safe state transitions after model changes), AI-TOOL.1 (witnessing each manufacturing command), AI-SUPPLY.1 (tracking who pushed the update and from where).
| Dimension | Centralized Factory | Distributed Micro-Factory | Builder-Owned Robotics |
|---|---|---|---|
| AI ownership | Factory operator | Robotics company | AI provider (remote) |
| Hardware ownership | Factory operator | Robotics company | Builder |
| Physical workspace | Factory operator's facility | Builder's construction site | Builder's facility |
| Building code liability | Builder | Builder | Builder |
| Machine safety liability | Factory operator | Robotics company (unless builder modifies) | Builder (operator) + AI provider (software) |
| Primary governance risk | No visibility into AI decisions | Environmental ambiguity | Split control, OTA drift |
All three models share one requirement: an immutable evidence chain from AI decision to physical output. The specific procedures differ, but the governance gap is identical. Without independent witness anchors, the only evidence of the AI's role in manufacturing is the AI provider's own logs -- which have no independent verifiability and are inadmissible as neutral evidence in liability disputes.
The following SWT3 procedures map to the governance requirements identified across all three liability boundary models. Each procedure produces independently verifiable evidence that can be presented to regulators, insurers, and legal counsel.
| SWT3 Procedure | Evidence Produced | Regulatory Requirement Addressed |
|---|---|---|
AI-TOOL.1 |
Witnessed record of each manufacturing command issued to a physical actuator | EU Mach Reg Art. 3 (safety component traceability), IBC (fabrication decision audit) |
AI-DEL.1 |
Delegation chain from design submission through AI interpretation to robotic execution | PLD Art. 7 (defectiveness), EU Mach Reg Art. 10 (manufacturer post-market obligations) |
AI-SAFE.1 |
Witnessed state transition for each operational mode change in a factory cell | EU Mach Reg Art. 3 (safety functions), ISO 10218 Cl. 5.4 (safety control systems) |
AI-CHAIN.1 |
Coordination evidence for multi-device operations within a manufacturing cell | ISO 10218 Cl. 5.10 (multi-robot coordination), MHS safety limit enforcement |
AI-MDL.2 |
Model version record for every AI update deployed to manufacturing equipment | EU Mach Reg Art. 18 (substantial modification), PLD Art. 7 (post-deployment changes) |
AI-PROV.1 |
Provenance chain linking a specific manufactured component to the exact model version | PLD Art. 7 (defectiveness), IBC (fabrication traceability) |
CON-STR.1 |
Building code requirement vs. AI-computed value for structural parameters | IBC/IRC Table 2308.5.1 (structural compliance), IBC Section 2308.5.1 (stud size, height, spacing) |
CON-INS.1 |
Inspection attestation with checklist results, inspector identity, and verification timestamp | OSHA 1926.20(b)(2) (frequent inspections), IBC (certificate of occupancy) |
HBOM-INV.1 |
Hardware bill of materials for each robotic manufacturing cell | EU Mach Reg Art. 3 (technical documentation), ISO 10218 Cl. 5.2 (robot identification) |
AI-DRIFT.1 |
Behavioral drift detection for manufacturing AI models over time | EU Mach Reg Art. 18 (substantial modification detection), Art. 10 (post-market surveillance) |
In AI-driven manufacturing, every command to a robotic arm, saw, fastener, or conveyor is a decision with physical consequences. AI-TOOL.1 witnesses each command as it occurs, creating a tamper-evident record that is independent of the AI provider's own logging infrastructure. The witness anchor captures the command identity, the timestamp, and the outcome -- without recording proprietary manufacturing logic.
Regulatory mapping: EU Machinery Regulation Article 3 requires traceability for safety-relevant components. Building codes require that fabrication decisions be auditable. AI-TOOL.1 provides both without requiring access to the AI provider's internal systems.
For a robotic fabrication cell, the number of AI-TOOL.1 anchors for a given production run should correlate with the number of manufacturing steps in the design translation. A wall panel with 14 studs and 280 fastener placements should generate a proportional evidence trail. A production run with significantly fewer anchors than expected manufacturing steps indicates gaps in witness coverage -- commands were issued without independent attestation.
When a builder submits a design file to a factory operator's AI system, an implicit delegation occurs: the builder authorizes the AI to interpret the design and translate it into manufacturing instructions. AI-DEL.1 witnesses this delegation chain, recording who authorized what scope at each boundary crossing. In multi-entity manufacturing arrangements, the delegation tree must cross organizational boundaries.
Regulatory mapping: Product Liability Directive Article 7 requires determination of which entity's decisions led to a defect. EU Machinery Regulation Article 10 requires manufacturer post-market monitoring of the decision chain. Without delegation witnessing, liability disputes devolve into finger-pointing between the builder and factory operator.
In centralized factory arrangements, verify that AI-DEL.1 anchors show an explicit authorization event for each design file submission. The delegation scope should be bounded -- "fabrication instructions for design DH-PHX-1142" rather than open-ended authority. If the delegation tree shows the factory AI making decisions outside the scope of the original design submission (e.g., substituting materials or modifying structural parameters), that is a governance finding.
Factory cells cycle through multiple operational modes: startup calibration, active fabrication, tool change, maintenance, material loading, and emergency shutdown. Each transition is a safety-critical event. AI-SAFE.1 witnesses the transition itself -- confirming that the cell moved from one validated state to another through a controlled process, not through an unplanned jump.
Regulatory mapping: EU Machinery Regulation Article 3 requires that safety functions be documented and verifiable. ISO 10218 Clause 5.4 requires safety-rated control systems for all operational modes. A factory cell that jumps directly from idle to full-speed fabrication without a calibration transition is a safety control system failure.
Verify AI-SAFE.1 anchors exist for every mode transition in the factory cell's operating cycle: power-on to calibration, calibration to production-ready, production-ready to active fabrication, active fabrication to tool change, and any transition to emergency stop. A missing transition -- especially from idle directly to active fabrication, bypassing calibration -- is a red flag indicating that safety interlocks may have been overridden or that the AI initiated production without completing pre-flight checks.
Modern robotic manufacturing cells contain multiple coordinated devices: cutting robots, nailing robots, transfer conveyors, vision systems, and material handlers. These devices must operate in sequence and sometimes in parallel, with precise timing. AI-CHAIN.1 witnesses the handoff between devices, recording the chain of operations that produced a single manufactured component.
Regulatory mapping: ISO 10218 Clause 5.10 specifies requirements for multi-robot installations including coordinated motion and shared workspace safety. MHS safety limits define per-device operating envelopes that must be respected during coordinated operations.
For multi-robot factory cells, all devices participating in a coordinated operation should generate anchors that share the same cycle identifier. A framing station with a cutting robot, nailing robot, and transfer conveyor should produce a linked chain of evidence for each panel. If one device in the cell has no anchors for a production cycle where other devices were active, that device operated without independent witnessing during a coordinated sequence -- a coverage gap that undermines the integrity of the complete chain.
In the builder-owned robotics model, the AI provider pushes model updates to robots that the builder owns and operates. Each update changes the AI's behavior on the builder's machine. AI-MDL.2 witnesses the model version transition, creating an independent record of what changed, when, and from where. This is critical because the builder may not know an update occurred until the next component fails inspection.
Regulatory mapping: EU Machinery Regulation Article 18 defines "substantial modification" as any change that affects conformity with safety requirements. Every OTA model update to a physical manufacturing system is a candidate substantial modification event. Product Liability Directive Article 7 holds the entity responsible for post-deployment changes that introduce defects.
In the builder-owned robotics model, every AI-MDL.2 anchor after the initial deployment represents a potential Article 18 substantial modification event. Article 18 uses four cumulative criteria: (1) made after placing on market, (2) not foreseen by the manufacturer, (3) affects safety by creating a new hazard or increasing existing risk, and (4) requires new protective measures. Verify that each model update has a corresponding baseline comparison showing whether the update moved the system's outputs outside its validated envelope. An OTA update that changes fastener placement accuracy by even a small margin could shift a previously compliant system into non-compliance with building code tolerances. If the update was foreseen and documented in the original conformity assessment (analogous to FDA's Predetermined Change Control Plan concept), it may not trigger Article 18 -- but the PCCP-equivalent documentation must exist in the anchor chain. The absence of AI-MDL.2 anchors on a system that is known to receive OTA updates is itself a finding.
When a structural defect is discovered in an AI-fabricated component -- weeks, months, or years after installation -- the first question is: which model version made the manufacturing decisions for this component? AI-PROV.1 witnesses the provenance chain, linking the physical output back through the model version, training lineage, and configuration state at the time of fabrication.
Regulatory mapping: Product Liability Directive Article 7 requires evidence of which decisions led to a defect. Building codes require fabrication traceability for structural elements. Without model provenance, a defect recall cannot be scoped -- you cannot determine which other components were made by the same model version. No regulatory framework currently exists for AI-version-based product recalls; the FDA's Predetermined Change Control Plan (PCCP) for AI medical devices is the closest template.
For post-incident forensics, verify that AI-PROV.1 anchors can reconstruct the complete provenance chain: from a physical panel's lot number to the production run, to the model version active during that run, to the model's training data lineage. If a defect is found in a panel produced on Tuesday, the provenance chain should identify every other panel produced by the same model version -- enabling targeted recall rather than blanket recall of all AI-fabricated components.
When an AI system determines structural parameters -- stud spacing, fastener patterns, load-bearing member dimensions -- those values must comply with the applicable building code. CON-STR.1 witnesses the comparison: the code requirement, the AI's computed value, and the inspection method used to verify compliance. The AI's output is measured against the code, not against its own training distribution.
Regulatory mapping: IBC Table 2308.5.1 and IRC Table R602.3(5) specify stud size, height, and spacing requirements for every load-bearing element. IBC Section 2308.5 governs conventional light-frame construction including AI-fabricated components. CON-STR.1 provides the evidence that the AI's computed values met the applicable code requirements.
Verify that CON-STR.1 anchors capture three distinct values: the building code requirement (e.g., maximum 16-inch stud spacing per IBC Table 2308.5.1 for load-bearing walls supporting one floor plus roof), the AI's computed value (e.g., 15.8 inches), and the verification method (AI vision system, physical sensor, or licensed inspector measurement). Note that 24-inch OC is permitted for walls supporting roof and ceiling only -- the anchor must record which load condition applies. Also verify which code edition the AI referenced: jurisdictions adopt different editions (e.g., Gilbert, AZ currently enforces the 2018 IRC, two editions behind the 2024 publication). An AI trained on IRC 2024 tables deployed in a 2018-jurisdiction could produce non-compliant output. If the AI's computed value equals the code limit exactly with no margin, flag for review -- manufacturing tolerances mean the physical result will deviate from the computed value, and a zero-margin design leaves no room for fabrication variance.
Every AI-fabricated structural component must pass inspection before installation. CON-INS.1 witnesses the complete inspection event: how many checklist items were evaluated, how many passed, the inspector's identity, and the timestamp. This creates an independent record that supplements the inspector's own documentation.
Regulatory mapping: OSHA 29 CFR 1926.20(b)(2) requires frequent and regular inspections of job sites, materials, and equipment. Building codes require inspection records for the certificate of occupancy. CON-INS.1 provides a tamper-evident attestation that the inspection occurred and what the result was.
Compare inspection pass rates between AI-fabricated and traditionally constructed components on the same project. AI-fabricated components should show equal or higher consistency due to manufacturing precision. If AI-fabricated components show a lower pass rate or higher variance than manually constructed elements, investigate manufacturing AI drift -- the model's output quality may be degrading over time, or environmental conditions at the fabrication site may be affecting quality.
A robotic factory cell is itself a complex system: robotic arms, end effectors, vision cameras, pneumatic tools, conveyors, controllers, and safety interlocks. HBOM-INV.1 witnesses the hardware inventory of the cell at a point in time, creating a baseline against which component swaps and upgrades can be detected.
Regulatory mapping: EU Machinery Regulation Article 3 requires technical documentation of machinery composition. ISO 10218 Clause 5.2 requires robot identification and documentation. A factory cell with undocumented component swaps -- a replacement saw blade with different cut characteristics, a sensor upgrade with different tolerances -- may produce different output from the same AI instructions.
For multi-robot cells, each robot should have its own HBOM-INV.1 attestation, and the cell-level inventory should reference all individual device inventories as a composite. A component swap that creates a delta from the certified baseline -- replacing an end effector, upgrading a vision camera, or reflashing a controller -- may require re-assessment if the changed component performs a safety function or affects manufacturing precision. Verify that HBOM-INV.1 attestations are refreshed after any maintenance event, not just on a calendar schedule.
AI models that control dimensional accuracy, material selection, or fabrication sequencing can drift over time -- through gradual parameter shift, environmental influence, or cumulative effects of incremental updates. In physical manufacturing, model drift manifests as physical defects: panels that are 2mm too narrow, fasteners that are 5mm off-center, or cuts that are not square. AI-DRIFT.1 detects these behavioral changes before they accumulate into structural non-compliance.
Regulatory mapping: EU Machinery Regulation Article 18 defines substantial modification to include accumulated behavioral changes, not just discrete updates. Article 10 requires manufacturers to conduct post-market surveillance including monitoring for drift. Without drift detection, a system can gradually move outside its validated envelope without any single update triggering a review.
For AI models controlling dimensional accuracy, verify that AI-DRIFT.1 monitoring covers the critical manufacturing measurements: stud spacing, panel width and height, fastener placement density, and cut angles. Drift thresholds should be set tighter than building code tolerances -- if the code allows plus or minus 3mm, the drift alarm should trigger at plus or minus 2mm, leaving margin for fabrication variance. A manufacturing AI that drifts to the edge of code tolerance has no safety margin left, and the next incremental shift will produce non-compliant output.
Anthropic's Model Hardware Standard (MHS), announced August 2026, standardizes how AI agents interact with physical devices. MHS uses two universal primitives -- read (query a sensor or device state) and write (command an actuator or change a device parameter) -- that every MHS-compatible device implements. Each device driver also stores a machine-readable reference file containing the device's physical characteristics, safety limits, and adjustable parameters.
MHS is built on the Model Context Protocol (MCP), which means every MHS device interaction is structurally a tool call. This is significant for governance: the same witnessing infrastructure that records AI software tool calls can record AI commands to physical hardware. The control plane (MHS) handles device communication. The witness plane (SWT3) handles independent evidence creation. They operate on parallel tracks -- neither depends on the other, and neither can tamper with the other's records.
Launch partners for MHS include Universal Robots and Doosan Robotics (both major industrial cobot manufacturers), AWS, Automata, Danaher, QIAGEN, and Tecan. Raspberry Pi is integrating MHS across several products. Hugging Face is adding MHS support to its LeRoBot library. As MHS adoption expands into manufacturing and construction robotics, every MHS write command to a robotic arm, saw, or fastener becomes a witnessable event.
Protocol separation matters: MHS provides no audit trail, no conformity assessment mapping, and no CE marking pathway. It is a control protocol, not a governance protocol. SWT3 does not control devices and has no access to manufacturing logic. It is a witness protocol, not a control protocol. The two are complementary by design. For a detailed mapping of MHS's six safety layers to SWT3 procedures, see the MHS Governance Crosswalk.
The following matrix maps the 10 SWT3 procedures in this guide against seven regulatory requirement areas relevant to AI-driven physical manufacturing.
| Procedure | Mach Reg Art. 3 | Mach Reg Art. 18 | ISO 10218 Cl. 5.4 | MHS Safety | Building Code | PLD Art. 7 | Post-Market Art. 10 |
|---|---|---|---|---|---|---|---|
AI-TOOL.1 |
✓ | ✓ | ✓ | ✓ | |||
AI-DEL.1 |
✓ | ✓ | |||||
AI-SAFE.1 |
✓ | ✓ | ✓ | ||||
AI-CHAIN.1 |
✓ | ✓ | |||||
AI-MDL.2 |
✓ | ✓ | ✓ | ||||
AI-PROV.1 |
✓ | ✓ | ✓ | ||||
CON-STR.1 |
✓ | ✓ | |||||
CON-INS.1 |
✓ | ✓ | |||||
HBOM-INV.1 |
✓ | ✓ | ✓ | ||||
AI-DRIFT.1 |
✓ | ✓ | ✓ |
Key observations:
AI-TOOL.1 has the broadest coverage across requirement areas, reflecting that every physical AI action is simultaneously a safety event, a building code event, and a liability event.CON-STR.1) and fabrication traceability (AI-PROV.1, AI-TOOL.1) -- the code must be met and the evidence must trace back to the AI that determined the parameters.The following examples demonstrate how a factory cell would report witnessed manufacturing events to the SWT3 ledger. These use the standard SWT3 ingestion endpoint -- the same API used by all SWT3 witness implementations across any deployment model.
import hashlib, time, requests
ENDPOINT = "https://your-instance.example.com/api/v1/witness"
API_KEY = "axm_your_key"
def witness_event(procedure: str, description: str, details: dict):
"""Post a witnessed manufacturing event to the SWT3 ledger."""
payload = {
"procedure_id": procedure,
"agent_id": "factory-cell-phoenix-01",
"jurisdiction": "US",
"legal_basis": "IBC-2024",
"observations": {
"description": description,
"timestamp": int(time.time() * 1000),
**details
}
}
resp = requests.post(
ENDPOINT,
json=payload,
headers={"Authorization": f"Bearer {API_KEY}"}
)
return resp.json()
# Witness a fabrication command (AI-TOOL.1)
witness_event("AI-TOOL.1", "Panel fabrication command issued", {
"tool_name": "panel_fabrication",
"design_id": "DH-PHX-1142",
"outcome": "completed"
})
# Witness structural verification (CON-STR.1)
witness_event("CON-STR.1", "Stud spacing verified against IBC", {
"code_requirement": "16 inch max per IBC 2308.5.1",
"computed_value": "15.8 inches",
"verification_method": "sensor"
})
# Witness inspection result (CON-INS.1)
witness_event("CON-INS.1", "Panel inspection completed", {
"items_required": 12,
"items_passed": 12,
"inspector_verified": True
})
const ENDPOINT = 'https://your-instance.example.com/api/v1/witness';
const API_KEY = 'axm_your_key';
async function witnessEvent(
procedure: string,
description: string,
details: Record<string, unknown>
) {
const resp = await fetch(ENDPOINT, {
method: 'POST',
headers: {
'Authorization': `Bearer ${API_KEY}`,
'Content-Type': 'application/json'
},
body: JSON.stringify({
procedure_id: procedure,
agent_id: 'factory-cell-phoenix-01',
jurisdiction: 'US',
legal_basis: 'IBC-2024',
observations: {
description,
timestamp: Date.now(),
...details
}
})
});
return resp.json();
}
// Witness a fabrication command (AI-TOOL.1)
await witnessEvent('AI-TOOL.1', 'Panel fabrication command issued', {
toolName: 'panel_fabrication',
designId: 'DH-PHX-1142',
outcome: 'completed'
});
// Witness structural verification (CON-STR.1)
await witnessEvent('CON-STR.1', 'Stud spacing verified against IBC', {
codeRequirement: '16 inch max per IBC 2308.5.1',
computedValue: '15.8 inches',
verificationMethod: 'sensor'
});
// Witness inspection result (CON-INS.1)
await witnessEvent('CON-INS.1', 'Panel inspection completed', {
itemsRequired: 12,
itemsPassed: 12,
inspectorVerified: true
});
For production deployments, the SWT3 SDKs (Python, TypeScript) provide higher-level abstractions including automatic batching, retry logic, and clearing level management. The raw API approach shown above works with any language or platform capable of making HTTPS POST requests.
The governance gap in AI-driven manufacturing is not theoretical. The insurance industry is already pricing it -- and in some cases, refusing to cover it.
On January 1, 2026, the Insurance Services Office (ISO, a Verisk subsidiary) rolled out three new commercial general liability endorsements: CG 40 47, CG 40 48, and CG 35 08. CG 35 08 specifically excludes bodily injury or property damage arising from autonomous systems and robotics from standard CGL policies. These endorsements were added at renewal without requiring policyholder opt-in. A builder whose CGL policy now contains CG 35 08 has no coverage for harm caused by AI-fabricated structural components -- and may not know until a claim is filed.
The exclusion creates a coverage void. If a wall panel fabricated by a factory operator's AI system fails after installation, the builder's CGL may deny the claim outright. The factory operator's product liability policy covers defective products, but may argue the AI's decision was within specification at the time of fabrication. The gap between "within specification" and "caused harm" is where litigation lives -- and where independent witness evidence determines the outcome.
Koop AI's "In Bots We Trust 2026" report -- based on five years of underwriting data from 392 U.S. robotics firms -- provides the most empirical evidence base for physical AI risk. Key findings:
Specialized AI liability products are emerging: Munich Re's aiSure program offers up to $15 million in coverage. Lloyd's-backed Testudo (launched January 2026) covers mid-market enterprises up to $9.25 million. Armilla AI offers $25 million standalone AI liability policies through Chaucer at Lloyd's. But none of these products are construction-specific, and none require governance evidence as a condition of coverage -- yet.
When evaluating a physical AI deployment's risk posture, verify whether the deployer's CGL policy contains Verisk endorsement CG 35 08 (autonomous systems exclusion). If it does, the deployer has no general liability coverage for AI-caused harm, making the SWT3 evidence chain the primary documentation for liability disputes. Request the policy's AI/robotics endorsement schedule. If the deployer has purchased standalone AI liability coverage (Munich Re aiSure, Armilla, or similar), verify that the policy's definition of "AI system" encompasses the specific manufacturing AI in use -- some policies exclude industrial process control or limit coverage to conversational AI only.
No lawsuit has yet been filed involving an AI-fabricated construction component. But the legal theories that will govern such cases are already being established in adjacent domains.
Garcia v. Character Technologies, Inc. (M.D. Fla., 2025) -- A federal court allowed product liability claims to proceed against an AI model developer by treating the AI as a product rather than a service. This distinction matters: product liability is strict (no need to prove negligence), while service liability requires proof of fault. The ruling opens the door for treating any AI system that generates physical manufacturing instructions as a component-part manufacturer of the resulting physical output.
Jimenez (California Supreme Court) -- Established that manufacturers of defective component parts installed in mass-produced homes are subject to strict liability in tort when those components cause harm to other parts of the home. This precedent applies directly to AI-fabricated structural components: if a Promise Robotics-manufactured wall panel contains a defect that damages the surrounding structure, the component manufacturer faces strict liability regardless of negligence.
Together, these cases establish a two-step theory: (1) the AI that generated fabrication instructions is a product (Garcia), and (2) the manufacturer of components installed in homes faces strict liability for defects (Jimenez). An AI-fabricated structural component that fails inspection or causes harm exposes both the factory operator and the AI provider to strict product liability claims.
The revised Product Liability Directive 2024/2853 (transposition deadline December 9, 2026) introduces several provisions that directly address AI-driven manufacturing:
On September 7, 2026, China's Supreme People's Court issued 24 articles establishing judicial rules for AI disputes. Key provisions: where vehicle defects and driver fault combine, courts support claims against both the manufacturer and the operator (joint liability). AI service providers who "effectively control the decision" bear liability even if the user triggered the action. Misrepresenting automation levels creates independent manufacturer liability. These rules apply to industrial AI systems, not just consumer products.
For physical AI deployments targeting the EU market, verify that the evidence chain documents all five factors that courts must consider under PLD Article 7(2): presentation and characteristics (a), reasonably foreseeable use (b), post-market learning behavior (c), interaction with other products (d), and the moment the product left the manufacturer's control (e). For deployments where the AI receives OTA updates, verify that each update is witnessed (AI-MDL.2) because Article 11 eliminates the development risk defense for post-deployment software changes. The burden of proof effectively shifts to the manufacturer in AI cases -- the evidence chain must be built proactively, not reconstructed after an incident.