Hardware V&V still runs mostly by hand, and the results scatter across notebooks and shared drives. Workflow Logs are the piece of Istari Digital that records the V&V you automate — every result pinned to the exact design version it ran against.
Software automated the grind. Hardware didn’t.
Systems and mechanical engineers lose a significant chunk of their week to repetitive, non-value-add work — manually reconciling data between vendor-locked tools, reworking designs when quarterly meetings expose cross-org dependencies, and executing basic test suites by hand. Software engineers long ago automated this kind of grunt work with CI/CD (continuous integration and delivery) — the approach of automatically compiling and testing code every time someone changes it. Hardware engineering never got the equivalent.
What Istari Digital does
Istari Digital is built to break down the barriers that cause this. It’s an open, programmable hardware product ecosystem that gives no-fail industries agentic access to their existing sources of truth in vendor-neutral, machine-readable formats. That lets teams run automated workflows across tools, collaborate securely across organizational and security boundaries, and execute V&V automatically and auditably.
What Workflow Logs are
Istari Digital provides an SDK (software development kit) for orchestrating complex workflows across your engineering tools. Istari Digital itself brokers the heavy lifting — it executes functions and jobs inside each tool and versions everything it touches. The orchestration that ties those steps together runs where it’s most flexible: in your own scripts, notebooks, and CI pipelines. Workflow Logs are the feature that closes the loop: they let you track those external workflows and tie their results to a specific configuration of your models inside Istari Digital.
Istari Digital terminology
Jobs, agents, and modules are the core of Istari Digital’s architecture. An agent is a small piece of software installed where your engineering data lives. Paired with a module — basically a translator for a specific tool like CATIA or PTC Windchill, or an internal one — the agent runs jobs against that data on command, under the permissions an admin grants and using a provisioned license if required.
Workflows chain those jobs together — and any off-platform analysis — into an end-to-end task, written in Python against the SDK by customers or Istari Digital’s forward-deployed engineers. A Workflow Log then records each run’s result against a configuration of a specific system (a set of models tracked together).
Two examples
The rest of this post walks through two examples to illustrate how you might use Workflow Logs to accelerate engineering work.
The first demonstrates automated V&V on a single part. A design engineer runs a battery of software-defined checks against an L-bracket; when one fails, they revise the design and re-run the checks to confirm the fix. Each result is logged against the exact version of the model using Workflow Logs — an audit trail that builds itself.
The second orchestrates a full design-and-test sweep — CATIA to gmsh to Nastran — to find the wing length for a UAV that maximizes range without breaking. Istari Digital runs and versions every job; a Python script drives the sweep and computes each design’s flight range. Every result is logged, so revisiting the study never means hunting for which CAD version produced which stress number.
Example 1: automated V&V on a design change
This example is fully documented in Istari Digital’s public cookbook — a collection of runnable sample notebooks (“recipes”) for the SDK. Here we walk through it briefly; open the notebook to run it yourself as a learning exercise.
Steps 1–2 lay the groundwork in Istari Digital: connect the SDK, then create a fresh System with the bracket’s STEP file tracked. (You could also create the System by hand in the web app.)
scenario_a.ipynb · §1–2 connect + create the System
# connect the SDK - two clients share one Configuration
client = Client(config) # models, systems, jobs
v3 = V3Client(config) # workflow outputs + log entries
# seed the initial R3 bracket, then create a System that tracks its STEP file
bracket_step.write_bracket(src, fillet_radius_mm=3.0, wall_thickness_mm=3.0)
model = client.add_model(path=src, display_name="bracket.step", description="Bracket - initial R3 design")
system = client.create_system(NewSystem(name="Workflow Log Walkthrough"))
config_obj = client.create_configuration(system_id=system.id,
new_system_configuration=NewSystemConfiguration(name="baseline",
tracked_files=[NewTrackedFile(specifier_type=TrackedFileSpecifierType.LATEST, file_id=model.file.id)]))
Steps 3–4 run the external workflow: a software-defined battery of checks against the STEP file. It catches that the stress at one of the fillet radii exceeds the allowable limit.
scenario_a.ipynb · §3–4 run the checks
# pull the tracked file back out of Istari, then run the checks locally
source_bytes = client.get_file(file_id=FILE_ID).revisions[-1].read_bytes()
results = run_battery(source_bytes, work / "artifacts") # ten software-defined checks
overall = "SUCCESS" if all(r.passed for r in results) else "FAILED" # -> FAILED: stress at the R3 fillet junit = write_junit(results, work / "artifacts" / "results.xml", src.name)
Steps 5–6 are where Workflow Logs come in. The result is recorded in Istari Digital, pinned to the most recent configuration of the System — the one holding that exact version of the STEP file.
scenario_a.ipynb · §5–6 log the result
# upload each output, then create ONE entry pinned to the active configuration
upload_paths = [junit] + [r.artifact_path for r in results]
output_ids = []
for p in upload_paths:
wo = v3.create_workflow_output(system_id=SYSTEM_ID, path=p)
output_ids.append(wo.id)
entry = v3.create_workflow_log_entry(
system_id=SYSTEM_ID,
workflow_log_entry_create_dto=WorkflowLogEntryCreateDto(
title="Verification battery - iter-1 (initial design)",
status=overall, # SUCCESS | FAILED
configuration_id=CONFIG_ID, # pin to this version
workflow_output_ids=output_ids,
),
)
Steps 7–9. The engineer now has the feedback they need. They enlarge the fillet to R5, re-run the same pipeline — this time it passes — publish a second entry, and attach the verified report back onto the model so the evidence rides with the CAD.
scenario_a.ipynb · §7–9 revise, re-run, log SUCCESS
# enlarge the fillet to R5 and commit a new revision of the tracked model
bracket_step.write_bracket(src, fillet_radius_mm=5.0, wall_thickness_mm=3.0)
client.update_model(model_id=MODEL_ID, path=src, version_name="v2-R5-fillet")
istari_helpers.commit_changes(client, SYSTEM_ID, CONFIG_ID)
# re-run the SAME battery against the new revision -> it passes -> log a SUCCESS entry
results = run_battery(client.get_file(file_id=FILE_ID).revisions[-1].read_bytes(), work / "artifacts2")
# ... then the same two calls as before: create_workflow_output + create_workflow_log_entry(status="SUCCESS")
This is a simplified version of a real engineering workflow, but it demonstrates what Workflow Logs unlock.
Today, running CI/CD-style checks on hardware is painful — you find a machine to run the FEA, get access provisioned, wrangle export formats — and even then the result vanishes into whatever notebook you ran it in. With Istari Digital, your engineers run those checks every day, and every verdict lands on the record, pinned to the exact version it tested.
Run it yourself - scenario_a, the design-loop recipe
Example 2: a wing sweep across three tools
Where Example 1 used a quick calculation to stand in for the stress check, this example orchestrates a workflow across the design tools engineers actually use: it drives geometry in 3DEXPERIENCE CATIA, meshes in gmsh (an open-source mesher), and solves FEA in MSC Nastran. It also shows how Workflow Logs make the resulting digital thread more robust.
The design challenge is to find the viable range of wing lengths for a UAV. A longer wing gives more lift and more range — but it’s also a longer cantilever, so the stress at the root climbs. Too short and it can’t reach the mission range; too long and the wing can’t take the maneuver load. The answer is the window in between.
The manual loop
The toolchain spans three programs — CATIA, gmsh, and Nastran. By hand, checking a single wing length means being the interface between all of them:
The options today
Without Istari Digital, there are two ways to run that loop across many designs — and neither is good
Do it by hand and you’re personally clicking through all nine steps for every single design — it’s so tedious that a handful is all anyone ever actually does. Write a custom script and you have to work out how to talk to each tool — and often the specific machine on your network that runs it. Either way, you leave behind no real audit trail, or one buried in a notebook only you can read.
How Istari Digital solves it
Istari Digital orchestrates the loop for you and uses Workflow Logs to build an automatic audit trail as it runs:
The core of the workflow is one function, evaluate. Its only input is L, the wing length under test, and it runs the five steps of the loop:
- Drive the CAD. The CATIA agent sets
WING_LENGTHon the live UAV model at its source (@istari:update_parameters). - Extract the geometry. The same agent runs two extracts —
@istari:extract_geometrywrites a STEP file (the neutral CAD snapshot that captures the model at this wing length, and the version Istari Digital tracks), and@istari:extractwrites an.obj, CATIA’s basic surface mesh of the model (along with other vendor-neutral artifacts the pipeline doesn’t use). The wing here is a single solid — no internal ribs or spars — so the.objis just its outer surfaces. - Mesh it. The Python script picks the wing out of the
.obj— dropping the fuselage and the rest of the aircraft — then uses gmsh to refine that coarse mesh into a finer, cleaner analysis mesh, fine enough to compute stress on. (This runs locally in the Python script, between the SDK-driven CATIA and Nastran agent jobs.) - Solve it. Nastran solves the shell model on an Istari Digital agent (
@istari:run). Because the mesh is a surface, not a solid, the FEA is given a representative skin thickness (6 mm, the design’s wing-skin value); the wing is clamped at the fuselage carry-through and loaded with the lift from its worst-case maneuver, and the peak von Mises stress comes back — one number to check against the limit. - Score and check. The mission range is estimated from the wing’s aerodynamics, and both requirements are tested: far enough, and not over-stressed.
-
wing_pipeline · one design: CATIA → gmsh → Nastran
def evaluate(L): # L = WING_LENGTH (mm)
drive_wing(client, catia, L) # CATIA · @istari:update_parameters
step, obj = extract_wing(client, catia, L) # CATIA · @istari:extract (OBJ) + @istari:extract_geometry (STEP)
info = isolate_wing(obj) # isolate the wing from the .obj (drop the fuselage)
XYZ, tris = refine_wing(info["stl"], size=25.0) # gmsh · refine into an analysis mesh
bdf = build_shell_bdf(XYZ, tris, L, info["chord"]) # thin-shell deck: clamp + maneuver lift
f06 = solve_shell(client, bdf) # Nastran · @istari:run (on an Istari agent)
stress = stress_metrics(vm_by_element(f06))["peak"]
return dict(L=L, range_km=range_km(L, info["chord"]), stress=stress)
The sweep then calls evaluate across five wing lengths and logs each design against the two requirements. log_design wraps the same
create_workflow_output and create_workflow_log_entry calls from Example 1:
the sweep · one Workflow Log entry per design
for L in [1900, 2150, 2400, 2650, 2900]: # WING_LENGTH sweep (mm)
row = evaluate(L)
passed = row["range_km"] >= 235 and row["stress"] <= 45 # RNG-001, STR-001
# freeze this design as a configuration, then log the verdict - the mesh, the
# von-Mises render, the Nastran .f06, and a JUnit report ride along as evidence
log_design(client, v3, system_id, row, tracked_files, reqs) # -> Workflow Log entry (SUCCESS | FAILED)
Each Workflow Log entry captures two things:
- The configuration it ran against — the CATIA model at its source, the STEP geometry extracted at that wing length, and the version of the requirements it was checked against. That is a governed commit — the same idea version control uses for code: one System tracking all three together.
- The evidence the run produced — the gmsh mesh, the von Mises render, Nastran’s raw
.f06results file, and a per-requirement pass/fail report in JUnit format (the test-report format software CI already uses). -
The result
With the sweep complete, every design comes together in one view — meshed, solved, and checked.
The payoff
- Time. Nobody spends the day clicking through CATIA or babysitting a one-off script. The SDK is the loop — point it at a range of wing lengths and it runs them.
- Auditability. Every design is a governed commit with a PASS/FAIL Workflow Log entry. Six months from now, anyone can open the sweep and see which wing length was checked against which requirement, and how it came out.
-
Workflow Logs make V&V part of how you design
Without Istari Digital, V&V is burdensome and slow — so it waits for milestones and gets done all at once, late. With Istari Digital Workflow Logs,
your checks run automatically and audit themselves, so V&V stops being a phase at the end and becomes part of how you design — on every change you make, and across every candidate you explore.
And a single engineer’s loop is only the start. Picture the same discipline across a whole program — subsystem integrations checked against each supplier’s latest revision, or an airworthiness case run a hundred times in simulation before the first physical test, every result on the record. That is what unlocks the next level of speed and quality across your org.
Start here image links:
- Workflow Log SDK guide: https://docs.istaridigital.com/developers/SDK/v3/workflow-logs
- Workflow Logs in the platform: https://docs.istaridigital.com/users/user-guide/systems#workflow-log
- Runnable recipes on Github: https://github.com/Istari-digital/istari-digital-cookbook/tree/main/samples/workflow-logs
- SDK walkthrough: https://docs.istaridigital.com/developers/SDK