Catch naming drift before an Abaqus run: a deterministic contract-audit pattern in Python

A developer has released an open-source Python tool that audits Abaqus finite-element model contracts for naming drift and incomplete evidence before solver runs. The deterministic preflight checks references such as loads and regions, producing stable reports with PASS and REVIEW_REQUIRED findings, while separating machine-checkable facts from engineering judgment. The project, abaqus-agent-skills v0.3.0, is Apache-2.0 licensed and independent of Dassault Systemes.

Disclosure: I maintain the open-source repository described below. This article was prepared with AI assistance and reviewed before publication. Automation failures in finite-element projects are often blamed on the solver, but many failures begin earlier. A script renames a region while a later load still points to the old name. An output request no longer covers the quantity needed by a review. A report calls a result "approved" even though the solver and physical-review gates are incomplete. These are contract problems. They are useful to detect before launching a licensed application or handling a large model. In this tutorial I will use a small, dependency-free Python demo to show the pattern. git clone https://github.com/1348109517/abaqus-agent-skills.git cd abaqus-agent-skills git checkout v0.3.0 python scripts/run demo.py --scenario complete The complete synthetic contract produces: PASS: 8 WARNING: 0 REVIEW REQUIRED: 0 The command writes report.json and report.md . Both reports are derived from the same ordered finding objects. They contain an input SHA-256 digest but no runtime timestamp by default, so rerunning an unchanged contract yields deterministic review artifacts. Now run the committed failure case: python scripts/run demo.py --scenario naming-drift Its summary is: PASS: 7 WARNING: 0 REVIEW REQUIRED: 1 The C-REF-001 finding points to loads.Gravity.region . The load refers to ExcavationFaceRenamed , while that region is not declared by the contract. The command still exits successfully because the auditor completed its job; the finding is a structured request for human review, not a Python crash. This separation matters in CI. An invalid JSON shape or an I/O failure should fail the tool. A valid contract containing an engineering-review finding should produce a stable artifact that a person or later workflow can inspect. python scripts/run demo.py --scenario evidence-overreach This scenario also returns seven passes and one REVIEW REQUIRED finding. C-EVIDENCE-001 records that an engineering claim was marked approved before the declared solver and physical-review gates were complete. The key rule is intentionally conservative: static contract review = solver evidence solver completion = physical correctness physical review = automatic claim approval A deterministic preflight can verify names and declared dependencies. It cannot choose a constitutive model, judge mesh adequacy for a specific claim, interpret an ODB, or certify an engineering conclusion. The public example uses synthetic data only. For another workflow, start with a small schema that names producers and consumers explicitly: parts, instances, regions, materials, steps, loads, output requests, and evidence gates. Keep machine-checkable references separate from decisions that require domain judgment. Prefer a status such as REVIEW REQUIRED when automation has reached its evidence boundary. Repository: https://github.com/1348109517/abaqus-agent-skills https://github.com/1348109517/abaqus-agent-skills Verified v0.3.0 release: https://github.com/1348109517/abaqus-agent-skills/releases/tag/v0.3.0 https://github.com/1348109517/abaqus-agent-skills/releases/tag/v0.3.0 The project is early-stage, Apache-2.0 licensed, and independently maintained. It is not affiliated with or endorsed by Dassault Systemes or SIMULIA. It does not include Abaqus, official documentation, solver binaries, or private model data. If the project is useful in your workflow, star the repository to follow its development. I would also appreciate a reproducible issue report or a proposal for another synthetic contract failure; those concrete cases are more useful at this stage than broad adoption claims.