Single-Path Artifact Pipeline

From RTL and Rust to robotics and human language under one container image

Author

Affiliation

SSCCS Foundation

Published

May 30, 2026

Abstract

The SDBS container image serves as a single base that carries the full toolchain for architectural emulation, hardware verification, and document generation. Three traditionally separate artifact pipelines – Rust-level emulation, RTL-level design, and published documentation – converge into one path where each layer validates and feeds into the next. The same pipeline pattern extends to robotics platforms such as HexaField (hexapod robot running ROS2 with SSCCS core logic) and to LLM-driven natural language interfaces, suggesting a unified approach to artifacts spanning low-level hardware up to human-language knowledge.

Other Formats

LLMs

Three Layers, One Image

A hardware design project typically maintains three independent artifact pipelines with little or no integration:

Layer	Toolchain	Artifact	Pipeline
Emulation	Rust compiler, test runner	Reference implementation, test results	Separate CI, separate image
RTL	Yosys, Verilator	Gate-level netlist, simulation	Separate CI, separate image
Documentation	Quarto, LaTeX, Python	Published site, PDFs	Separate CI, separate image

Each pipeline has its own container image, its own build script, its own CI workflow, and its own deployment target. Changes at one layer propagate to the others only through manual coordination – a Rust API change that invalidates the RTL model goes undetected until someone notices the discrepancy.

The SDBS-based pipeline collapses these three into a single path:

Figure 1: Three layers converge into one artifact pipeline under the SDBS base image

All three layers share the same base image. The Rust compilation, the RTL verification, and the document generation run inside the same merged container, accessing the same workspace volume. Any change at any layer – a Rust type signature, a SystemVerilog module port, a documentation page reference – is validated in the same CI run, against the same codebase snapshot.

Artifact Convergence

The consequence of a single base image is that the three layers produce artifacts that are structurally connected:

Rust source (poc/)              → cargo test   → test results
SystemVerilog source (sv/)      → verilator    → simulation output
                                  → sv2dot.py   → DOT diagrams
DOT diagrams + Quarto source     → sdb build   → HTML site, PDFs
                                  → _llms/      → agent knowledge base
                                  → R2 S3       → Nexus ingestion

The RTL gate-level diagrams are generated by a Python script running inside the same container that also runs the Rust test suite. The diagrams appear in the documentation as embedded Graphviz figures. The documentation is built by sdb build, the same CLI that the SDBS image ships. The agent knowledge base is extracted from the same build output.

There is no separate “documentation update” step after a design change. Updating the Rust reference implementation or the RTL source triggers the full pipeline, and the published documentation reflects the new state at the end of the CI cycle. The three artifacts converge into one deployment:

Figure 2: Single deployment contains artifacts from all three layers

Comparison with Separate Pipelines

Concern	Separate images, separate CIs	Single SDBS-based image
Rust emulation	One Dockerfile, one workflow	Same image, same workflow
RTL verification	Another Dockerfile (Yosys, Verilator), another workflow	Same image, same workflow
Documentation build	Third Dockerfile (Quarto, LaTeX), third workflow	Same image, same workflow
Cross-layer validation	Manual or nightly integration test	Every CI run validates all three
Design-to-docs latency	Days to weeks (manual diagramming)	One CI cycle (minutes)
Agent knowledge base	Separate extraction pipeline	Built from same `sdb build` output
Container maintenance	Three Dockerfiles to update	One base image, one POC layer

The single-base approach does not reduce the total toolchain size – Yosys, Verilator, and Rust are still installed – but it eliminates the coordination cost between layers. Each CI run validates the full stack: if the Rust emulation, the RTL model, and the documentation all agree, the result is a coherent cross-layer snapshot. If any layer disagrees, the failure is detected immediately rather than surfacing days later in a separate integration check.

Extension to Robotics and Physical AI

The same pipeline pattern extends beyond the current scope. The HexaField project – an 18-degree-of-freedom hexapod robot running ROS2 with SSCCS core logic – demonstrates how the artifact pipeline generalizes to physical systems:

Field parameters (slope, payload)  → field_to_gait (Rust)   → gait parameters
LiDAR scans + IMU data             → Nav2                   → navigation commands
Voice commands                     → STT + local LLM        → JSON action
Joint feedback                     → ros2_control           → servo commands

All of these are Observation events in the SSCCS model: sensor inputs act as Field constraints, the Observation produces a Projection (joint trajectory or navigation path), and the resulting behaviour is deterministic with respect to the current Field state. The same sdb build pipeline that produces documentation from RTL source could, in principle, ingest HexaField’s URDF model, ROS2 node interfaces, and demonstration results into the same knowledge base.

The HexaField project uses the same SSCCS primitives (Segment, Scheme, Field, Observation, Projection) that the POC emulates in Rust and the RTL implements in SystemVerilog. Adding HexaField’s documentation and test results to the same sdb build corpus would extend the artifact pipeline to cover physical robotics as a fourth layer.

Natural language interfaces (voice commands → local LLM → Nav2 costmap adjustment) add a fifth layer. The LLM is a minority component in the same sense described in the accumulative knowledge note: called only when a new knowledge branch must be opened. The STT-to-JSON pipeline produces structured Field constraints that feed into the same Observation mechanics.

Relation to Accumulative Knowledge

The accumulative knowledge architecture described in the neXus project notes treats LLMs as a minority component – called only when accumulated knowledge is insufficient to answer a query. The same principle appears here in a different domain: the build artifact (merged container) is produced once and consumed by multiple downstream processes without redundant computation. The expensive operations – Rust compilation, Yosys synthesis, Verilator elaboration – run exactly once per CI cycle. Downstream jobs consume the cached result.

Both patterns share the same operational form: invest once in a durable intermediate representation, consume it many times in parallel. In neXus the intermediate representation is the verified Fact graph; in this pipeline, it is the layer-cached container image. The difference in domain should not obscure the structural similarity.

Scope

These observations describe a specific pipeline design for one project where the SDBS image serves as the common base. The HexaField extension is a projected application: the core SSCCS abstractions are shared, but the HexaField-specific documentation and CI integration have not been built. The extent to which this approach applies to other hardware-documentation or robotics-documentation workflows depends on toolchain compatibility and CI infrastructure. No claim is made about universal applicability.